Поиск по этому блогу

четверг, 13 декабря 2012 г.

Проблемная аутентификация с Axis

Недавно возникла потребность создания клиента с аутентификацией для веб сервиса с Axis. При этом если следовать инструкции в самом acis достаточно прописать лишь:
          // If authorization is required
          service.setUsername(name);
          service.setPassword(password);
А при билде получаем Exception
AxisFault
 faultCode: {http://xml.apache.org/axis/}HTTP
 faultSubcode: 
 faultString: (401)Unauthorized
 faultActor: 
 faultNode: 
 faultDetail: 
 
....
(401)Unauthorized
 at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java)

Лечится это довольно просто: так как axis1 использует класс устаревший HTTPSender, в котором и возникает ошибка, то его можно заменить на CommonsHTTPSender. Для этого в проект добавляем commons-httpclient-3.1.jar (именно 3.1,так как другие версии могут не содержать этот класс) и commons-codec.jar. Для этого в классе, который наследует org.apache.axis.client.Service, добавляем метод
 protected org.apache.axis.EngineConfiguration getEngineConfiguration() {
        java.lang.StringBuffer sb = new java.lang.StringBuffer();
        sb.append("\r\n");
        sb.append("\r\n");
        sb.append("\r\n");
        sb.append("\r\n");
        sb.append("\r\n");
        sb.append("\r\n");
        org.apache.axis.configuration.XMLStringProvider config =
                new org.apache.axis.configuration.XMLStringProvider(sb.toString());
        return config;
    }
И вызываем его в конструкторе. С Axis2 таких проблем уже нет. После генерирования stub из WSDL достаточно прописать лишь:
Options options = stub._getServiceClient().getOptions();
          HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
          auth.setPassword(password);
          auth.setUsername(name);
          options.setProperty(HTTPConstants.AUTHENTICATE,auth);

четверг, 6 декабря 2012 г.

Обзор литературы за последнее время

  1. "Экстремальное программирование" Кент Бек
    Отличное руководство для тех, кто хочет перейти на на такую методологию разработки как экстремальное программирование. Рассмотрены условия перехода, основные моменты методологии, сложности и преимущества. Для затравки - основные тезисы экстремального программирования:
    • Игра в планирование(planning game)
    • Небольшие версии(small releases)
    • Метафора(metaphor)
    • Простой дизайн(simple design)
    • Тестирование(testing)
    • Переработка(refactoring)
    • Программирование парами(pair programming)
    • Коллективное владение(collective ownership)
    • Непрерывная интеграция(continuous integration)
    • 40-часовая неделя(40-hour week)
    • Заказчик на месте разработки(on?site customer)
    • Стандарты кодирования(coding standards).
    Из недостатков - в книге не отделены особенности ЭП от других agile методологий.
  2. "Гибкие методологии разработки" Б. Вольфсон
    В книге представлены основные положения всех agile методик, есть выдержки из манифеста о гибкой разработке, также представлены особенности всех известных разновидностей данной методике, где на первое место выходит scrum и экстремальное программирование.
  3. "Экстремальное программирование: разработка через тестирование" Кент Бек
    И снова от Кента Бэка отличная книга о test driven development. Тут четко, послеовательно, шаг за щагом приводят тебя к необходимости тестов в целом и перед началом работы над задачей в частности. Из классики (c)

    TDD заключается в следующем:
    1. Быстро создать новый тест.
    2. Запустить все тесты и обнаружить, что новый тест не выполняется.
    3. Внести небольшие изменения.
    4. Снова запустить все тесты и на этот раз зафиксировать, что все они успешно срабатывают.
    5. Провести рефакторинг (refactoring) для устранения дублирования.

  4. "Паттерны проектирования" Э. Фримен, Э. Фримен, К. Сьерра, Б. Бейтс
    О паттернах сейчас знают все, но, тем не менее, не все их применяют. Наверное, все начинали знакомство с ними по знаменитой книге банды четырех, но сколько потребовалось усилий, чтобы запомнить где нужно применять фасад и что такое паттерн обозреватель?
    Данная книга легко и ненавязчиво, а, главное, на очень доступных примерах объясняет суть большинства самых употребляемых паттернов. Так что до знакомства со справочником от банды четырех рекомендовала бы эту книгу.
  5. "SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055) (Certification Press)" Katherine Sierra Книга будет полезна не только, готовящимся к SCJP, но и всем людям которые хотят знать инструмент, повседневно используемый в работе, в совершенстве.
  6. После прочтения некоторых книг хочется выделить авторов-создателей толковой, полезной и легкочитаемой технической литературы. На первом месте, безусловно, для меня Стив Макконел, с его кодом, оценками продуктов, UML. А в этом списке выделились Кэти Сиера и Кент Бек.

среда, 11 июля 2012 г.

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 кода:

понедельник, 9 июля 2012 г.

С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 у методов:
      
         
         
           
      

пятница, 6 июля 2012 г.

Coberture + maven

Пожалуй, уже некого убеждать о важности юнит-тестов в программировании, и многие используют каждый день такие инструменты как:
Данная статья является просто быстрым стартом использования 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/):

понедельник, 26 марта 2012 г.

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

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