Sonar + Maven3 + multimodule project

Недавно на проекте возникла таинственная ошибка: при выполнении sonar:sonar сборка валилась с ошибкой, которая якобы вызвана невозможностью обработать некий класс (имя класса не имеет значение). Весь стектрейс заканчивался вот такой строчкой:
cause at: org.sonar.api.resources.DuplicatedSourceException: ИМЯ_КЛАССА


Загадочная эта ошибка по нескольким причинам:
1. Проект полностью собирается, и со всеми классами все нормально
2. Эта ошибка воспроизводится только на Linux (та же сборка на Windows машине происходит нормально)
3. Тем, как она разрешилась :)


Гугление вывело на вот этот тикет. Там идет довольно длинное обсуждение похожей проблемы, и все заканчивается вот такой фразой:
After some investigation, I found out that the problem was the maven-javadoc-plugin version 2.6. After updating to 2.7 every is working fine now!

"Но у нас в проекте не собираются JavaDoc-и" была первая мысль. "А что, если попробовать добавить?". Добавил... и sonar:sonar сразу заработал:)

Цифры

Некоторые выводы:

Цифры/сроки

От 20% до 50% времени уходит на активности "около работы". Т.е. если эстимейт предполагает на 1 мес. разработки, то все может затянутся на 2 календарных месяца.


Зависимость кол-во оверхедов от длинны проекта не линейная. Если проект маленький - оверхеды маленькие. Скорее всего потому, что к проекту относятся как к чему то временному и не существенному.
Если проект средний (12-18 ес), то оверхед просто громадный. Объем работ не сильно большой, а подготовка/бюрократия уже "не детская" (тяжеловесные подходы к организации процессов).
Если проекты большие, то оверхеды начинают теряться в общей массе (по появляются др. моменты, связанны с "затяжными прыжками").


Напряженная работа начинает напрягать где то к концу 2-3 недели. Появляется дискомфорт и чувство усталости. Ритм 2 недели "по полной", потом неделя "на расслабоне" дает неплохие результаты.

Овертаймы начинают чувствоваться к начал след. недели. 5 дней + овертаймы + еще пару дней - еще можно работать. Далее начинается спад продуктивности, внимательности и т.д. Как можно работать 5-7 недель без выходных - для меня загадка...

Общение с заказчиком

Отсутствие обратной связи от заказчика, начинает напрягать уже к концу 2-го релиза. ~1 недели молчания после поставки достаточно, чтобы команда немного напряглась. К 2-3 релизу это перерастает в легкую форму пофигизма.

В среднем, задержка полноценного фидбека может достигать 1 релиз. Делаем уже 5-й, а получаем окончательную информацию только по 3-му. Календарное время - примерно 1-2 мес.

Наверное стоит держать контекст фичь еще, как минимум 1 мес. после релиза. А лучше 2-3.

Акцент заказчика может оказаться самым неожиданным для вас. 70% вопросов задаются по "очевидным" для вас моментам. 25% по мутным и недостаточно документированным фичам, и 5% вопросов обращаются к по настоящему проблемным местам, которые не были известны вам.

коммиты/поток изменений

Самый большой барьер - начало.
Начало проекта. Необходимо приложить все мыслимые усилия, чтобы в начале проекта работа началась. Первые 10-20 коммитов очень важны. Нужно лить что угоно (струкру директорий, скелет проекта, шаиблоны и документу) - не важно, важно чтобы лед тронулся. Когда люди начинают работать с СВН и ВИКИ, то начинают появляться вопросы, начинаются шевеления и команда начинает движение вперед.
Начало релиза. В начале релиза наблюдается провал. Не такой громадный, как на старте проекта, но все же... Старое сделали, новое еще не начали. Что делать? Когда и с чего начинать? Главные и второстепенные цели этого релиза. Надо приложить максимум усилий, чтобы ответить на эти вопросы (и донести ответы до команды). Без этой информации наблюдается штиль. Возможно, лучшим вариантом было бы начать отвечать на эти вопросы уже в конце прошлого релиза (умным языком "начинать планировать следующий релиз, в конце ткущего"), но в реальной жизни небольших команд не всегда это получается. Релизы обычно довольно напряженные, основной фокус - поставка, а вопросы анализа и планирования как то теряются.


Максимум активности - середина и конец релиза. Середина - все на крейсерской скорости. Конец - все "в теме", и происходит куча небольших исправлений (допиливаний). Начало релиза - не совсем понятно с чего начинать и иногда требуется доработка дизайна.

Русский в консоли

Печально, но до сих пор приходится ковыряться с проблемами локализации в Linux.
В Ubuntu (10.10, 11.04 и 11.10) в виртуальных консольках (tty1-6) не отображается русские буквы. Самый простой способ исправить:
sudo apt-get install console-cyrillic
dpkg-reconfigure console-setup
dpkg-reconfigure console-cyrillic
sudo nano /etc/rc.local
В конец, перед выходом, добавляем setupcon:

setupcon
exit 0

SUN/Oracle JDK + Ubuntu 11.10

В последней версии Ubuntu пакеты 'sun-java6' убрали из всех репозиториев. Есть 2 способа пофиксать эту проблемму (если OpenJDK по каким то причинам не подходит):

Manual

В ручную скачать установщик, установить его и зарегистрировать все что надо (см: здесь).
Способ чуть сложнее, но в результате получаем самую свежую версию (и более ясное понимание что и где лежит).

PPA repository

sudo add-apt-repository ppa:ferramroberto/java
sudo apt-get update
sudo apt-get install sun-java6-jdk sun-java6-plugin
sudo update-alternatives --config java
Способ заметно проще и быстрее, но последняя доступная версия 1.6.0_26.

"Интересный" проект

Текущий проект подходит к концу. Скорее всего, это один из самых "тяжелых случаев" в мое практике. У нас случилось все: и набор команды "с нуля", и неизвестные/малодокументируемые технологии, и полная неразбериха с ресурсами (и временем и баблом), и критическая концентрация идиотов на душу населения мешающих факторов, и траблы с железом, и необходимость разбираться с тем, чего так долго удавалось избегать(например multithreading и JS).

Но все таки было интересно. Во первых на небольшом проекте все процессы происходят чуть активней. Поэтому лучше видна реакция как на положительные факторы/решения, так и на отрицательные. Во вторых "общая картина" более очевидна и контролируема, поэтому ответить на вопросы "зачем мы это делаем" и "к чему мы движемся" было намного проще, чем на проектах, которые начались пару лет назад и неизвестно когда закончатся.

(перепост) Устройство некоторых технологических компаний (Open University посвящается)

http://wanderer-from.livejournal.com/118144.html

m2eclipse - "обновился" :(

Довольно давно пользуюсь планигом m2eclipse.
До недавнего времени он имел скромную версию 0.10.xx, при весьма внушительной функциональности.
И вот наступило "время первого взрослого релиза" - 1.0.xxx...

Результаты заставили меня призадуматься.
Все началось с того, что с новым плагином перестал собираться имеющийся проект. Проект уже налаженный (на Maven 2.2.1), довольно небольшой, и ничего особенного с точки зрения сборки. Но, "внезапно", pom.xml засветился красненькими ошибками и начались танцы с бубном.

Попытки понять "что происходит" привели к 2 интересным открытиям:
Открытие 1. "Sonatype has completed the transition of the M2Eclipse project to Eclipse. Please go to this URL for M2E information: http://eclipse.org/m2e".
Хм... новость настораживает, потому как при дружественных слияниях и прочих подобных движениях, качество и стабильность продукта обычно падает (по крайней мере у первых версий).

Открытие 2. Новая версия плагина стала настолько крута, что 2/3 настроек просто убрали... например, теперь невозможно определить какие goals будут выполняться во время сборки и очистки проекта...

Выводы:
Почитал... попробовал... и понял что есть 2 выхода:
1. Остаться на проверенной v0.10 или v0.12 (благо, sonatype-овский update site еще работает). Попутно можно ждать новых релизов, и надеяться на лучшее.
2. Попробовать нечто новое, например Eclipse IAM.

Пару слов о MS Project

Заметка про горячие клавиши и еще пару интересных моментов.

Немного о строках (перепост)

java.lang.String: вы уверены, что знаете про строки все?.
Довольно занимательная статейка.

VirtualBox: авто запуск виртуалок

После установки VirtualBox 4.x встали 2 вопроса:

• автозапуск - некоторые виртуалки нужно запускать одновременно с host сервером
• корректное завершение работы, т.е. автоматическое и корректное выключение виртуалок вместе с host сервером

После усиленного гугления выяснилось, что:
а) родными средствами VirtualBox-а эти задачи не решаются
б) есть некоторое кол-во самописных скриптов, но...
в) все они некорректно работают с VB v4.x.
Пришлось брать, и "допиливать"...

Установка Apache Archive на Ubuntu Server

Из цикла '1001 велосипед'.

Есть такая замечатлеьная програмка как Archive. Помогает сэкономить кучу времени и нервов разработчикам, работающим с Maven проектами (особенно актуально для контор, не могущих позволить себе нормальный интернет канал).
Так вот, есть следующая задача:
а) установить это чудо на Ubuntu Server (ssh, без XServer-а)
б) сделать автоматический запуск и остановку
в) разнести исполняемый код\конфиги и данные по нужным даректориям
г) сделать это с минимальными исправлениями самого дистрибутива archiv-ы

С первым пунктом вроди-бы все понятно. Со вторым - болие или менее. С третиьим - пришлось чуть чуть помудрить, потому как приложение написано так, что все находится в одной папке (бинарники, конфиги, базы данных и кеш артифактов).

Перепост: Совершенствование кода с помощью плагинов Eclipse

Статья Совершенствование кода с помощью плагинов Eclipse - обзор парочки плагинов для статического анализа кода. Средства простые 'до безобразия', но могут съэкономить кучу времени и нервов.

Замечание: статья 2007-го года, так что некоторая информация чуть устарела:
1. CheckStyle за последние несколько лет "чуть выросла". Одно из вкусных дополнений - это способность измерять\проверять циклическую слоность кода (CCN) и длину методов\классов (NCSS).
2. Coverlipse на данный момент выглядит какимто полузаброшенным проектом. В тоже время есть довольно неплохой плагин eCobertura.
3. Metrics - может оказаться ненужным, потому как базовые мтрики можно контролировать с помощью Checksyle\PMD.
4. Есть еще довольно спорный плагин для FindBugs. Спортный потому что, на сайте приведено довольно много "пафосных бла бла бла", но при этом управлять плагинами для maven и eclipse довольно проблематично (точнее не плагинами и наборами правил и исключений).

Перпост: Очищаем скрипты сборки от запахов

Небольшая статья о том, чего не надо делать со скриптами сборки:

Автоматизация для людей: Очищаем скрипты сборки от запахов

Еще мысля по Jenkins API

Интересная API у этой системы... заставляет чувствовать себя полным идиотом :(
Все, как будто, ясно, красиво и очевидно, но на реализацию простейших вещей уходит уйма времени.

Что помогает:

• Наличие комментариев. JavaDoc-и есть и они довольно объемные (иногда даже информативные).
• Наличие огромного количества примеров. Имеется ввиду уже написанных плагинов, а точнее исходников к ним.

Что мешает:

• Отсутствие высокоуровневой документации. Javadoc-и это конечно хорошо, но составить общую картину по ним довольно сложно. Разбирательство c API напоминает разгадывание ребуса (с применением накопленного опыта, интуиции и русского мата).
• Довольно высокий уровень косвенности. Множество вещей (модулей и сущностей) связаны неявными правилами и эти связи проявляются только в run-time. Узнать как правильно реализовывать некоторые виды плагинов довольно проблематично: информации из javadoc-ов не достаточно и посмотреть как они(плагины) обрабатываются самой системой тоже трудно. Спасают только примеры (плагины с аналогичной функциональностью).
• Довольно большая часть информации устарела (туториалы, документация, примеры): либо ссылки битые, либо API уже изменилась. Так что, выполнение первого туториала может вылиться в довольно долгую и увлекательную задачу.

Надо как то собраться с мыслями, и записать "накопанные" знания.

Java в Ubuntu

В Ubuntu по умолчанию стоит OpenJDK, что для разработчика 'как то не привычно'. Xочется видить и пользовать Sun JDK.

1. Разрешаем использовать пакеты из зеркал партнеров. Для этого:
- открываем /etc/apt/sources.list и раскоментриуем вхождения для restricted и pertner зеркал.
- обновляем список пакетов sudo apt-get update

2. Устанавливаем желаемую JDK:
sudo apt-get install sun-java6-bin sun-java6-jdk sun-java6-jre

3. Добиваемся использования Sun JDK вместо OpenJDK. Тут есть варианты:
3.1. Прописать в настройках приложений (например Eclipse) пути именно к /usr/lib/jvm/java-6-sun и на этом успокоится.
3.2. Изменить 'JDK по умолчанию': sudo update-alternatives --config java. Логика подсказывает, что это наиболее безопастный способ, но другая логика подсказывает, что держать на винчестере 2 экземпляра джавы как то не правильно (расточительно). Поэтому....
3.3. Полное удалени неиспользуемых пакетов. Лучше делать через Sinaptic: грохнуть все пакеты, которые начинаются с openjdk. В результате освобождаем 100-200 МБ

Вот так 404!

http://proteys.info/404/

Знакомство с Hudson

Пришлось познакомится с CI системой Hudson.
Первое впечатление очень даже ничего:

• при своей бесплатности, выглядит на редкость представительно и имеет кучу возможностей;
• довольно просто устанавливается и конфигурируется;
• для тех кому мало существующего функционала, есть возможность дописывать свои плагины. Кстати API выглядит довольно многообещающе;
• ну и естественно, кросплатформенное приложение.

На первый взгляд, система довольно легко может заменить такие продукты как TeamCity и Bamboo. А мрачное убожество СС здесь и рядом не стояло:)

Из минусов:

• для разработчика плагинов ну очень мало информации. Возможно я еще чего то еще не знаю, но пару обзорных статей и устаревших/не работающих туториалов как то не внушаю оптимизма;
• последние пол года проект как то колбасит. Видно что недавно они перехали на новый домен java.net + совсем недавно проект решил сменить свое название на Jenkins (тут и тут). И это, тоже, вносит свою долю неразберихи.