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

четверг, 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. "Как пасти котов. Наставление для программистов, руководящих другими программистами" Дж. Ханк Рейнвотер
    Эта книга полезна тем, кто выбирает себе дорогу менеджера в профессиональном плане. Часто бывает, что люди с большими техническими знаниями плохо руководят проектом. Данная книга позволяет взглянуть на управление проектом под немного другим углом.

среда, 7 марта 2012 г.

Code Highlight

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

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

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

В последнее время приходится теснее сотрудничать с 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 есть проблема с повторением фоновых изображений. К счастью, эта проблема может быть легко решена определением достаточно большого горизонтального смещения (настраивается).

четверг, 9 февраля 2012 г.

Фичи java 7 (Project coin) ч.1

Недавно вышла новая версия java с большим количеством нововведений и полезных фич. Описания новых возможностей в рунете не так много, поэтому и родилась статья.
Project coin - список наиболее юзабельных изменений.

1.String в конструкции Switch

С точки зрения чистоты кода - правильнее для этих целей использовать enum.
Но, с другой стороны, никто не мешает вместо строковых литералов в следующем примере использовать строковые константы. Зато, например, при написании юнит-тестов значительно может упроститься наша жизнь.
     private User getUserByRole(String userRole) {
        User newUser = null;
        switch (userRole) {
            case "admin":
                newUser = new Adminisitator();
                break;
            case "manager":
                newUser = new Manager();
                break;
            default:
                newUser = new User();
                break;
        }
        return newUser;
    }


2. Оператор <> (или в англоязычной версии "diamond operator")

Теперь никто не мешает написать
 List boo = new ArrayList<>();
Возможности добавить в список элемент,что имеет тип не Long, нет уже на уровне компиляции.

3. Числовые константы

Помимо всеобщих строковых литералов и констант, для повышения читаемости кода теперь можно прописывать числовые команды в двоичной системе и с подчеркиванием:
        int i = 0b11;
        Long num = 0b11111011010L;

        long bigCommon = 1000120500L;
        long bigReadbale= 1_000_120_500L;
        int iReadable = 0b1000_0000_0000;
4. Суффиксы в byte и short

Теперь помимо суффикса для Long, появились суффиксы для других типов.
1) S и s для short;
2) Y и y для byte.
        byte b1 = (byte)0x80;
        byte b2 = 0x80y;
        byte[] ba1 = {0x7F, (byte)0x80, (byte)0xFF};
        byte[] ba2 = {0x7F, 0x80y, 0xFFy};

5. Управление ресурсами

Теперь освобождение ресурсов может производится автоматически (вместо их освобождения в блоке finally, как было ранее):
    static String readFirstLineFromFile(String path) throws IOException {
        try (BufferedReader br = new BufferedReader(new FileReader(path))) {
            return br.readLine();
        }
        //ресурс закроется автоматически
    }

Это работает за счет добавления нового интерфейса AutoCloseable в java.lang. При этом интерфейс Closeable находится на уровень ниже, что делает все потоки автозакрываемыми.

6. Пробрасывание исключений и одновременная обработка нескольких исключений сразу

Теперь для обработки всех исключений вместо всего списка искобчений, что может генерировать функция достаточно прописать ключевое слово final и параметр типа Exception:
 public void readParams() throws IOException, IllegalAccessException{
        try {
            doSomething();
            // выбрасывает IOException, IllegalAccessException
        } catch (final Exception ex) {
            logger.log(ex);
            throw ex;
        }
    }

Также добавлен синтаксис для обработки нескольких исключений сразу:
public void readParams2(){
        try {
            doSomething();
            // выбрасывает IOException, IllegalAccessException 
        } catch (IOException | IllegalAccessException ex) {
            logger.log(ex);
        }
}

пятница, 20 января 2012 г.

Пример использования контрактного программирования в java (iContract)

Впервые встретилось описание контрактного программирования на хабре в одном из комментариев, да и в статье. А после прочтения "Программиста - прагматика" появилось желание попробовать технологию.

В общем контрактное программирование - это попытка формализовать

взаимодействие между элементами алгоритма - делать на выходе, то что оговорено, получая оговоренные условия на вход.


Read more!
В работе я часто встречала ситуации, когда, например, начало методов было проверкой параметров на Null. Или эта проверка была в середине, что, очевидно, не добавляло понимания в работу метода. К тому же часто эти проверки дублировались в многих местах, или, что намного хуже вообще пропускались, из-за чего был баг.

Вот именно из-за этой неразберихи со вводом-выводом контрактное программирование выглядит довольно привлекательным.

В целом, можно выделить 3 блока при работе с контрактами
1) проверка предусловий - типы данных, формально оговоренные состояния входной информации;

2) проверка постусловий - типы возвращаемого значения, условия, которым должны соответствовать выходные данные;

3) проверка инвариантов - проверка на соблюдение условий, которым должны удовлетворять инварианты на каждом шаге алгоритма.

Разбор контрактного программирования я начала, с самой известной библиотеки iContract.

  1. Пример проверки предусловий
  2. 
        /**
         * @pre positiveParam > 0 
         */
        public static void setPositiveParam(int positiveParam) {
            System.out.println("Set a param" + positiveParam);
        } 
    
  3. Пример проверки постусловий
  4.     /**
         * @pre word != null
         * @post getWord() != null
         */
        public static void setWord(String word) {
            _word = word;
        }
    
  5. Пример для инвариантов
  6.     /**
         * 
         * @invariant forall Object r_text in list 
         *   r_text!=null
         */
        public static void addNotNullValues(List list, Integer value)
            list.add(value);
        }
Подключается iContract добавлением jar файло в проект + добавлением target в ant.

Однако, как оказалось, это не самая удачная технология для бизнес-приложений, у которой есть множество аналогов: от Google, для Spring framework, и другие, например contract4j
Вохможно, в следующей части рассмотрю аналог от google.

вторник, 17 января 2012 г.

Программист-прагматик

Недавно на Хабре была статья о 5 лучших книгах по программированию.
Если "Совершенный код" давно занял место в моей библиотеке, то о "Программисте - прагматике" узнала только сейчас.
Из всех советов, что больше всего понравились из книги:
  • Узнать больше о возможностях своей операционной системы, IDE. Освоить консоль и горячие клавиши, механизмы автоматизации, что предоставляем твоя ОС.
  • Диверсификация навыков - не быть привязанным только к своему языку, технологии и тп.
  • Избегать "разбитых окон" - при малейшем ухудшении качества кода должны быть механизмы автоматизации и менеджмента в команде, которые мониторят проблемы и назначают ответственного за устранение неполадок.
  • Тестирование состояний, вместо тестирования только строк кода.
  • Жесткая борьба с дублированием, принцип DRY - Don't Repeat Youself во всех сферах - будь до код, будь то документация. Даже Фаулер в своем "Рефакторинге" не был так категоричен - том это было только одним из "душков".
  • Описание принципов контрактного программирования и примеры использования утилиты iContract
  • Краткое описание оценок алгоритмов