К основному контенту

Сообщения

Сообщения за 2012

Linux & MSIE. Веб-разработчику на заметку

В этом посте я хочу поделиться одной недавней находкой, которая будет полезна в первую очередь веб-разработчикам, являющимся по совместительству счастливыми пользователями Linux. Нам (а я один из таковых) приходится дополнительно решать одную небольшую проблему: создаваемый сайт необходимо протестировать в "горячо любимом" браузере от компании Microsoft. Скажу сразу, что тестировать сайт в MSIE под Wine не стоит. Вы будете видить не то, что ваши пользователи. Существует еще множество онлайн-сервисов, которые в обмен на адресс к вашему сайту выдадут пачку скриншотов. Эта опция подойдет далеко не каждому. Лучший известный мне способ - это воспользоваться виртуальной машиной с Windows на борту. Но где же её достать? Не вопрос, скажете вы. Можно самому потрудиться или пингануть знакомого админа. У меня есть еще один вариант: воспользоваться скриптом ievms.sh (вот она находка!) Этот скрипт создаст виртуалки для IE 6, 7, 8 и 9 (для каждой версии свою собственную машину) и заре

JavaDay 2012 в Киеве. Мои впечатления

27 октября в Киеве пройшла конференция JavaDay 2012. Не знаю точно сколько было участников, но человек 300, думаю, собралось. До обеда все были в одном зале. Из 4 докладов 3 было сделано представителями Oracle. Вначале Simon Ritter рассказал, в каком направлении планируется развивать платформу Java; напомнил, что Java ME не умерла и что они ориентируются не только на мобильные телефоны, но и на всякие встраиваемые девайсы. Конечно, он не мог не напомнить, что Java успешно работает на Raspberry PI. Simon признался, что это позор, конечно, что они не внедрили наработки проекта Jigsaw к релизу Java 8. При этом утверждал, что оно вроде как и готово, а отложили по причине множества мелких недоработок. Доклад завершился месседжем: “Java is not new Cobol”. Что ж, вполне ожидаемо :) Суховатость доклада разбавили ответы на вопросы. Забавно было услышать “Oracle thinks Scala is good”, а чуть позже, отвечая на вопрос о сотрудничестве Oracle и университетов Simon рассказал об Oracle Academy, но

Международный день борьбы с DRM

Сегодня международный день борьбы с DRM . DRM - растущая проблема в области электронных книг. Люди не могут свободно повторно продать или подарить их или переместить на новое устройство без повторного приобретения. Похожая ситуация и в области видео-контента. С подобным положением дел сложно мириться и люди во многих странах намерены сегодня протестовать против DRM. Больше информации на dayagainstdrm.org

Sonar и Eclipse

Итак, с основными возможностями платформы мы ознакомились и умеем находить нужную информацию. Но она вся за пределами среды разработки, а значит вне нашего фокуса. Разработчику эта информация нужна непосредственно в месте написания кода: так ошибки быстрее замечаются и исправляются и, как следствие, не накапливаются. Те же ошибки, которые, оставлены на потом, будут заметны и не забудутся. Я рассмотрю процесс установки и использования плагина для Eclipse. Для начала идем на Eclipse Marketplace, ищем по слову Sonar и нажимаем “Установить”. Прежде чем двигаться дальше, убедитесь, что Sonar запущен и в браузере вам доступна его страница. После этого связываем проект с Sonar. По непонятной мне причине в появившемся окне понадобится указать groupId и artifactId для вашего проекта. После этого открываете свой проект в перспективе Sonar и видите свои ошибки. Объем информации зависит от текущего выделения: пакет или класс Внизу доступны 3 вкладки Web, Hotspots и Violations. В них та же информ

Конфигурируем Sonar

Если использовать Sonar в реальных условиях на проекте размером чуть более среднего, использующего не один фреймворк, необходимость в конфигурировании возникает естественным образом. Ведь не все правила важны именно для вас, некоторые файлы неплохо бы и вовсе исключить, чтобы не проверялись (например, генерируемый код). До этого времени у нас не было необходимости логиниться: вся информация итак доступна. Но, чтобы сконфигурировать систему, необходимо быть администратором. Вбиваем в форму admin/admin и после входа в систему выбираем пункт Configuration (справа вверху). Вы увидите перед собой список профилей. По умолчанию их три: Sun checks, Sonar way и Sonar way with Findbugs (отличаются они набором правил, в каждом следующем их больше). Ни один из этих профилей нельзя изменить, а только использовать в качестве шаблона. Жмите кнопку копирования и редактируйте свой профиль: можно отключить некоторые правила или изменить их приоритет. На вкладке Projects новый профиль связывается с ва

Sonar и слабые места проекта

В этом посте скажу пару слов о выявлении слабых мест проекта (касательно качества кода, конечно). Разработчики Sonar'а предвидели, что в больших (и даже среднего размера) проектах недостаточно знать интегральное значение некоторого показателя и его распределение по классам. Важно выделить те несколько классов, в которых значение метрики существенно отклоняется от нормы. В Sonar'е для этого выделили отдельную панель (пункт меню Hotspots ), на которой можно посмотреть наименее оттестированные участки кода, найти наиболее времязатратные тесты, увидеть классы, сложность которых пугает, а также самые нарушаемые правила и ресурсы с наибольшим количеством нарушений. Вооружившись этой информацией, вы можете сконцентрироваться на исправлении основных недостатков, а остальное оставить на потом.

Sonar и метрики кода

В этом посте я, как и обещал, расскажу о метриках кода, представленных в правой части мониторинговой панели — это показатель спутанности пакетов ( package tangle index ), недостаток связности в методах ( LCOM4 ) и отклик для класса ( response for class ). Показатель спутанности пакетов Эта метрика учитывает циклические зависимости между пакетами. Это отношение между количеством циклических зависимостей и общим числом зависимостей. Понятное дело, что чем ближе этот показатель к 0, тем лучше. Чтобы увидеть циклические зависимости, щелкайте по значению показателя или выбирайте в левом меню пункт “Design”. Вот легенда к матрице, которую вы увидите Недостаток связности в методах Класс, как мы помним, состоит из полей и методов. В каждом из методов используется некий набор полей и/или вызываются другие методы. Методы связаны между собой, если один из них вызывается из другого, или они используют одно и то же поле класса. LCOM4 определяется количеством груп связанных методов в классе. Если L

Знакомим Sonar с кодом вашего проекта

Прошлый раз я забыл написать, что после старта платформы нужно зайти в браузер по адресу http://localhost:9000 (если, конечно, вы не разворачивали на своем JEE сервере с собственными настройками). Но вы все равно бы ничего интересного там не увидели. Ведь надо каким-то образом познакомить Sonar с кодом вашего проекта. В веб-интерфейсе этого не сделать (поверьте, я потратил некоторое время в поиске такой возможности — сэкономил на чтении документации :)). Для этого нам понадобится maven. Для начала надо поместить свой артефакт в локальный репозиторий maven. В переменную окружения MAVEN_OPTS записываем что-то вроде    -Xmx512m -XX:MaxPermSize=128m Можно и больше выделить памяти, если есть возможность. Потом даем команду    mvn sonar:sonar , если вы все еще используете версию 2.x или    mvn org.codehaus.sonar:sonar-maven3-plugin:2.13:sonar , если вы перешли на версию 3.x. После заветного “BUILD SUCCESSFUL” можно идти в браузер и обновлять страничку Sonar'а. Там вы увидите саму

Мониторинг качества кода. Платформа Sonar

После продолжительного затишья попробую возобновить свою блоггерскую деятельность. Так сложилось, что последнее время я оказываюсь в роли борца за качество кода. С одной стороны — заказчик, у которого сроки поджимают, а с другой — программист, следующий правилу: “Работает — не трогай!”. Кодовая база растет, в программе появляется новый функционал и вместе с тем накапливается технический долг, сказывающийся на стоимости сопровождения приложения и скорости добавления новых “плюшек”. До определенного времени мало кто обращает внимание на качество кода, считая его вполне приемлемым. Да, иногда вспоминаем про рефакторинг, что-то переделываем сразу, а, бывает, прикинув необходимые на его проведение временные затраты, откладываем в бэклог до лучших времен. Поди улови тот момент, когда качество было приемлемое, и “вдруг” оказалось никудышным. Значит, необходимо отслеживать качество кода. При этом желательно автоматизировать этот процесс. А так как потребность назрела давно, были разработаны н