Joda (http://joda.sourceforge.net/) - это группа java-проектов с открытым исходным кодом для расширения базовой функциональности jdk. В настоящее время включается в себя joda-money, joda-beans, joda-primitives, joda-convert и joda-time. Все библиотеки характеризуются узкой специализацией, небольшим размером, хорошим описанием и javadoc'ом, простотой и интуитивностью применения, совместимостью и удачным взаимодействием с jdk. Что же включает в себя эта группа и какие из них стОит поместить в свою "копилку" полезных библиотек?
пятница, 27 июля 2012 г.
пятница, 6 июля 2012 г.
//noinspection в IntelliJ IDEA
Как я уже упоминал в предыдущем посте, в IDEA есть интересный плагин InspectionGadgets, который на текущее время предлагает более 500 дополнительных проверок для этой IDE и является мощным инструментом статического анализа кода.
Инспекции этого инструмента весьма удобны в использовании, т.к. сгруппированы по содержанию и назначению и могут настраиваться индивидуально. Более того, результаты настройки можно сохранить в отдельный файл xml формата и загрузить его в IDE в другом месте. Ну, да разговор немного о другом. InspectionGadgets отслеживает и формирует гораздо больше предупреждений, чем java компилятор. И если требуется подавить какое-то из предупреждений, то аннотация @SuppressWarnings отлично работает. Но как узнать название нужного предупреждения, чтобы указать его в параметрах аннотации?
Инспекции этого инструмента весьма удобны в использовании, т.к. сгруппированы по содержанию и назначению и могут настраиваться индивидуально. Более того, результаты настройки можно сохранить в отдельный файл xml формата и загрузить его в IDE в другом месте. Ну, да разговор немного о другом. InspectionGadgets отслеживает и формирует гораздо больше предупреждений, чем java компилятор. И если требуется подавить какое-то из предупреждений, то аннотация @SuppressWarnings отлично работает. Но как узнать название нужного предупреждения, чтобы указать его в параметрах аннотации?
вторник, 3 июля 2012 г.
@SuppressWarnings: пример
@SuppressWarnings в java (list of warnings) список предупреждений
1) Praemonitus praemunitus (предупреждён, значит, вооружён)
Практически все компиляторы в процессе компилирования исходного программного кода выполняют статический анализ этого кода, что позволяет идентифицировать и предупреждать о наличии некоторых общих ошибок программирования. Положительный эффект заключается в том, что каждое имеющееся предупреждение - потенциальная проблема, и чем раньше эта проблема выявляется (в данном случае - уже на этапе компиляции), тем дешевле её решение. В целом, многие опытные разработчики придерживаются мнения, что конечный код не должен вызывать предупреждений компилятора. Более того, в некоторых компаниях идут дальше и настраивают политики систем контроля версий таким образом, чтобы коммиты не вызывали подобных предупреждений.
Однако жизнь такова, что иногда исключения из строгих правил всё-таки возникают. И оказывается, что в каком-то конкретном случае выдаваемое компилятором предупреждение легально, и что было бы здорово указать компилятору проигнорировать конкретное предупреждение. Как вообще можно управлять политикой предупреждений в java?
1) Praemonitus praemunitus (предупреждён, значит, вооружён)
Практически все компиляторы в процессе компилирования исходного программного кода выполняют статический анализ этого кода, что позволяет идентифицировать и предупреждать о наличии некоторых общих ошибок программирования. Положительный эффект заключается в том, что каждое имеющееся предупреждение - потенциальная проблема, и чем раньше эта проблема выявляется (в данном случае - уже на этапе компиляции), тем дешевле её решение. В целом, многие опытные разработчики придерживаются мнения, что конечный код не должен вызывать предупреждений компилятора. Более того, в некоторых компаниях идут дальше и настраивают политики систем контроля версий таким образом, чтобы коммиты не вызывали подобных предупреждений.
Однако жизнь такова, что иногда исключения из строгих правил всё-таки возникают. И оказывается, что в каком-то конкретном случае выдаваемое компилятором предупреждение легально, и что было бы здорово указать компилятору проигнорировать конкретное предупреждение. Как вообще можно управлять политикой предупреждений в java?
среда, 27 июня 2012 г.
Как запустить groovy-скрипт?
Помню, в первом семестре первого курса университета на занятиях по информатике от нас требовали знать X способов включения компьютера, Y способов запуска программы и Z способов завершения работы...
Наверное, разработчиков Groovy учили приблизительно тому же - иначе зачем они придумали столько способов запуска groovy-скрипта? Итак.
Наверное, разработчиков Groovy учили приблизительно тому же - иначе зачем они придумали столько способов запуска groovy-скрипта? Итак.
четверг, 21 июня 2012 г.
Groovy - знакомство
Groovy - объектно-ориентированный язык программирования для платформы Java. Соответственно, groovy использует java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками (ru.wikipedia.org/wiki/Groovy).
пятница, 1 июня 2012 г.
Best practices
Лучшие практики: поиск неисправностей
При изучении, анализе и тестировании приложения перед специалистами стоят задачи обнаружить проблемы (самого различного рода - функциональные, связанные со стабильностью работы или производительностью и многое другое), локализовать их, понять причины и найти пути к устранению.
В решении подобных задач помогают различные инструменты, как узкоспециализированные, так и достаточно широкого круга применения. Но важно понимать, что следует полагаться не только на удобные инструменты, но и должным образом организовывать работу, применять зарекомендовавшие себя методики - т. н. best practices. Естественно, практик много, они разные, имеют различные цели и могут быть полезны в определённых ситуациях.
В этой статье - сейчас и в будущем при апдэйтах - я планирую собирать практики, которые могут быть удобны при troubleshooting.
Каждая практика будет описываться буквально несколькими предложениями.
Практики будут собираться/проверяться конкретно для java-мира, хотя - на то они и "лучшие практики", чтобы не быть зависимыми от применяемых технологий.
При изучении, анализе и тестировании приложения перед специалистами стоят задачи обнаружить проблемы (самого различного рода - функциональные, связанные со стабильностью работы или производительностью и многое другое), локализовать их, понять причины и найти пути к устранению.
В решении подобных задач помогают различные инструменты, как узкоспециализированные, так и достаточно широкого круга применения. Но важно понимать, что следует полагаться не только на удобные инструменты, но и должным образом организовывать работу, применять зарекомендовавшие себя методики - т. н. best practices. Естественно, практик много, они разные, имеют различные цели и могут быть полезны в определённых ситуациях.
В этой статье - сейчас и в будущем при апдэйтах - я планирую собирать практики, которые могут быть удобны при troubleshooting.
Каждая практика будет описываться буквально несколькими предложениями.
Практики будут собираться/проверяться конкретно для java-мира, хотя - на то они и "лучшие практики", чтобы не быть зависимыми от применяемых технологий.
четверг, 10 мая 2012 г.
java.lang.OutOfMemory: JDK build-in analysis tools
Недавно услышал от одного из менеджеров удивлённое восклицание - "java и утечка памяти?! Как такое может быть?! В java же ведь нет утечек памяти!!!". К сожалению, этот менеджер был не прав, и утечки памяти - memory leak - в java всё-таки встречаются.
(Понимание причин требует знания модели памяти и работы сборщика мусора, в этом посте они не рассматриваются; в качестве обзора можно посмотреть, какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса)
Что же делать, если в один не очень прекрасный день в логе приложения обнаруживается строка "java.lang.OutOfMemoryError: Java heap space"?
Некоторую помощь - иногда достаточно полезную, а иногда единственно возможную - могут предоставить встроенные в JDK средства. Далее следует краткий обзор таких средств с полезными ссылками.
(Понимание причин требует знания модели памяти и работы сборщика мусора, в этом посте они не рассматриваются; в качестве обзора можно посмотреть, какие бывают типы OutOfMemoryError или из каких частей состоит память java процесса)
Что же делать, если в один не очень прекрасный день в логе приложения обнаруживается строка "java.lang.OutOfMemoryError: Java heap space"?
Некоторую помощь - иногда достаточно полезную, а иногда единственно возможную - могут предоставить встроенные в JDK средства. Далее следует краткий обзор таких средств с полезными ссылками.
Подписаться на:
Сообщения (Atom)