Паттерны для SimpleDateFormat

Ссылка на все паттерны для SimpleDateFormat: http://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html

Sonar + maven

Как подводные лодки исследуют морское дно и обнаруживают вражеские корабли с помощью такого прибора как сонар, так и opensource проект для анализа кода с идентичным названием Sonar позволяет, используя метрики, обнаружить недостатки в программе.

Установка Sonar

1. Загрузить последнюю версию Sonar тут и распаковать.
2. В settings.xml в maven (обычно лежат в $MAVEN_HOME/conf или ~/.m2) добавить новый профиль Sonar:

   
    sonar
    
     true
    
    
     
     
       jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
     
     com.mysql.jdbc.Driver
     sonar
     sonar
     
     
       http://localhost:9000
     
    
   
   

   Если в проекте используется БД, то прописываем соответствующие driverClassName, username и password.
   В любом случае необходимо прописать sonar.host.url.
3. Запускаем Sonar:
   $SONAR_PATH/bin/windows-x86-32/StartNTService.bat
4. А теперь можно проанализировать ваш проект, запустив
   mvn sonar:sonar

После этого ваш проект добавился к проектам, проанализированным с помощью Sonar.
Отчеты будут доступны по url, что вы прописали в sonar.host.url.

Вот так выглядит общая страница отчета по проекту:

• Показывает статистику по проекту, такую как количество строк, пакетов и тп.
• Количество комментариев и дубликатов.
• Соответветсвие стандартам по разным метрикам (в данном примере Rules compliance 81.8% ).
• Зависимости между пакетами.
• Уровень complexity (запутанности) кода.
• Результаты юнит-тестов и уровень покрытия кода

Каждый раздел можно посмотреть подробнее.

Например, покрытие тестами:

Или отчет complexity кода:

Сheckstyle (java) + maven

Для оценки соответствия кода заданным в команде стандартам могут использоваться разные утилиты, но чаще в моей практике использовалась Checkstyle
Часто Checkstyle используется для повышения качества кода в тех командах, где присутствует негармоничное соотношение джуниоров, интермидов и синиоров. Когда кода много в таких проектах, рефакторить его просто некому и некогда. Был в моей практике проект, где самая основная операция осуществлялась в одном методе с длиной порядка 1500 строк. Использовав эту утилиту, рефакторинг кода осуществился бы в принудительном порядке (например, параметры длина метода и code complexity).

Подключается плагин при помощи maven так:

 org.apache.maven.plugins
 maven-checkstyle-plugin
 2.6
 
  src/config/checkstyle.xml
  true
 
 
  
   package
   
    check
   
  
 

При этом обычно настраивают так, что при любом несоответствии стандартам билд ломается.

Основные элементы для настройки стиля:

1. Ограничения размеров
   • FileLength - ограничение на количество строк в файле:

   • LineLength - ограничение на длину строки для повышения читабельности кода:

   • MethodLength - ограничение на длину метода (ограничение, о котором говорилось выше):

   • ParameterNumber - ограничение на количество параметров в метода. Как известно, кода большое количество параметров у метода является "дурным запахом" и подлежит рефакторингу. В данном случае всего можно избежать заранее.

2. Метрики
   Также очень полезно использовать ограничения по основным метрикам кода
   • BooleanExpressionComplexity - ограничение на количество условий в boolean выражении:

   • CyclomaticComplexity - ограничение вложенность for, if, switch и тп конструкций. Величина "запутанности" кода:

3. Дубликаты. Любителям copy+paste посвящается :)
   • StrictDuplicateCode - длина кода, который при дублировании должен быть отрефакторен:

4. Стандарты именования
   • В данном случае представлен пример именования методов, классов, переменных

5. И не забываем javadoc.
   • JavadocType - наличие javadock у классов, интерфейсов, enum:

   • JavadocMethod - наличие javadock у методов:

Coberture + maven

Пожалуй, уже некого убеждать о важности юнит-тестов в программировании, и многие используют каждый день такие инструменты как:

• cobertura
• emma
• clover

Данная статья является просто быстрым стартом использования cobertura под Maven. Во-первых, для создания отчета о покрытии кода юнит-тестами достаточно просто прописать в pom:

    
        
            
                org.codehaus.mojo
                cobertura-maven-plugin
                2.5.1
            
        
    

А для того чтобы билд фейлился, если покрытие ниже заданного (ниже в примере задано покрытие не меньше 75%) прописываем уже не в , а в :

 
    
        
            org.codehaus.mojo
            cobertura-maven-plugin
            2.5.1
            
                
                    75
                    75
                    true
                    75
                    75
                    75
                    75
                
            
            
                
                    
                        clean
                        check
                    
                
            
        
    

При этом можно некоторым важным пакетам повышать покрытие кода:

    
        75
        75
        true
        75
        75
        75
        75
        
            
                com.mobiletech.aker.parsers.*
                75
                100
            
        
    

а некоторые пакеты "убирать" из базы анализа:

    
        
            org.codehaus.mojo
            cobertura-maven-plugin
            2.5.1
            
                
                    
                        com.example.boringcode.*
                    
                    
                        com/example/dullcode/**/*.class
                    
                
            
        
    

А вот так выглядит сгенерированный отчет (по умолчанию генерируется в /site/coberture/):

Несколько хороших книг

В последнее время попалось много хороших книг, которые содержат не только знание о конкретных технологиях, но и полезные советы о развитии личности программиста в профессиональном плане. Этим списком хочется поделиться.

1. "Совершенный код" С. Макконелл
   
   Об этой книге говорят многие, некоторые считают многие вещи, описанные в ней, очевидными. Но факт остается - если хочешь писать код, который будет легко поддерживаться другими людьми и на котором не стыдно будет поставить @author, то стоит почитать эту книгу.
2. "Паттерны проектирования" Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес
   
   Ставший классикой, сборник проверенных решений. "Банда четырех" проделала колоссальную работу по систематизации накопленного опыта рабочий решений задач проектирования, что позволяет не только ознакомится с ними, но и получить определенную лексику современного проектирования.
3. "Рефакторинг. Улучшение существующего кода" М. Фаулер
   
   Помимо хорошего стиля программирования, делать код более гибким к последующим изменениям и более читабельным позволяет рефакторинг. В данной книге собраны самые распространенные виды рефакторинга, описаны плюсы и минусы, показаны условия их использования. Большинство представленных видов рефакторинга интегрированы в современные среды разработки.
4. "Сколько стоит программный проект" C. Макконелл
   
   От автора "Совершенного кода" отличное пособие по улучшению собственной оценки времени, необходимого для решения задач
5. "Веб-Дизайн" Стив Круг
   
   Книга представляет собой введение в вебдизайн, а также знакомит с некоторыми принципами юзабилити для web приложений.
6. "Как пасти котов. Наставление для программистов, руководящих другими программистами" Дж. Ханк Рейнвотер
   
   Эта книга полезна тем, кто выбирает себе дорогу менеджера в профессиональном плане. Часто бывает, что люди с большими техническими знаниями плохо руководят проектом. Данная книга позволяет взглянуть на управление проектом под немного другим углом.

Code Highlight

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

• http://highlight.hohli.com/
• http://tohtml.com/

Слово о спрайтах

В последнее время приходится теснее сотрудничать с front-end разработкой, поэтому недавно познакомилась с такой вещью как спрайты. Вообще понятие спрайтов пришло к нам из игр, когда на одной картинке располагаются несколько мелких и нужная выбирается в зависимости от координат. Например, спрайт от известной ностальгической игры Super Mario.
В веб-приложениях такая технология способствует:

1. ускорению загрузки картинок сайта;
2. уменьшению количества запросов на сервер - вместо запросов к каждой картинке по отдельности, идет загрузка сразу всех.

Например, есть на сайте 4 картинки Соединить их в одну мы можем:

1. в любом графическом редакторе;
2. а можем воспользоваться любой веб-утилитой, например, spritegen.

В результате получается примерно такой результат:

Теперь касаемо CSS.
Если раньше стили были прописаны в таком формате:

.open{
background:url(open_window.png) 100% 100% no-repeat;
}

то теперь нужный фон устанавливается с помощью background-position (поддерживается всеми браузерами):

.sprite-open_window{
background-image: url(csg-4f54c057b225e.png);
background-position: 0 -163px; width: 30px; height: 30px; 
} 

Из прогугленных недостатков спрайтов:

• Opera (по крайней мере до версии 9.0) не признаёт позиции фона больше 2042px или меньше -2042px, используя вместо этого эти крайние значения. Этот инструмент исправляет это за счет создания новых колонок в выводимом изображении каждый раз, когда вертикальный предел достигнут.
• У Safari есть проблема с повторением фоновых изображений. К счастью, эта проблема может быть легко решена определением достаточно большого горизонтального смещения (настраивается).