о том, что 'должен делать разработчик'

Совсем недавно пришлось 'немного' побеседовать с манагерами разных мастей на тему 'что у нас плохо, а что хорошо и что с этим делать'. Я услышал довольно много разных 'разработчик должен делать' и некоторые пункты меня удивили. Вот некоторые из них:

• разработчик должен знать какого уровня железо требуется для проекта (CPU, память и т.д.). Если вдруг, рабочий ПК тормозит, то разработчик должен (ну просто таки обязан) разобраться в чем дело
• разработчик должен принимать самое активное участие в усовершенствовании процессов на уровне проекта и на уровне организации
• разработчик должен заниматься тестированием
• разработчик должен в совершенстве владеть всеми технологиями, применяемыми в проекте, и по другому просто не может быть

Отличия 'get X' от 'find X'

Наблюдение из разряда 'мелочи, которые облегчают жизнь' (и способствуют взаимопониманию).
Есть методы для поиска/получения 'нечто' и есть 2 основных разновидности поведения в случае, если результат не найден (или не может быть получен):

• вернуть null или пустую коллекцию
• толкнуть исключение (например ItemNotFoud)

Впервые на эту разницу обратил внимание в ORM framework-ах. Ка правило, если это метод getXXX, то он либо возвращает результат либо толкает исключение, а если это findXXX, то он возвращает результат либо пустое значение (null или пустую коллекцию).

Unit тестирование и Jackrabbit (JCR)

Вот есть такая замечательная поделка как Jackrabbit - кладязь сюрпризов и неожиданностей. И захотелось как то пописать тесты на классы, которые работают с этим Jackrabbit-ом.

Вообщем, есть такая задача:
Есть JCR репозиторий и есть некие модули, которые работают с этим репозиторием. Задача: создать среду для тестирования этих модулей.

Тестирование: начало (ч.2)

Размышления на тему: "что надо сделать, чтобы превратить загадочное слово 'тестирование' в нечто реально полезное для разработчиков?"
Ответить на ряд вопросов:
1. Чего мы хотим добиться?
2. Нужно ли нам это?
3. Можем ли мы это себе позволить?
4. Заниматься этим систематически, т.е. постоянно (это не вопрос, а утверждение).

Мысля о качестве ... и не только

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

CXF: Шаг 0 - XSD to Java

Почему шаг 0?

Почему шаг нулевой: на мой взгляд этот шаг имеет нулевую пользу и если это возможно, нужно его пропустить. Почему?

• Мы в этот файл вкладываем информацию о типах данных, которыми будем оперировать в интерфейсах. При преобразовании XSD to Java эта информация изменится (возможно довольно сильно), при преобразовании Java to WSDL получившаяся измененная информация еще больше исказится.
• Все комментарии, разметка и прочая вспомогательная информация, заложенная в XSD, уйдет "в никуда".
• Ну и куча "мелочей", от лишних 10 сек при компиляции до необходимости хранить знания об интерфейсе в двух раздельным местах на двух разных языках.

Если вышенаписанное не убедило отказаться от написания XSD или по другому не получается, то вот несколько рецептов "от головной боли":

Экономия или скупость?

Лирическое вступление

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

Вот работал я в организациях где к вопросу железа подходили ну довольно просто, в 3 этапа:
1.Со старта дают нормальный (достаточно мощный ПК)
2.В случае надобности, делают апгрейд в довольно короткие сроки (1-10 дней).
3.И сервера, как правило, работают на действительно серверных железках (а не хламе, который остался от прошлого апгрейда).

А вот бывают случаи противоположные. На проекте хронических дефицит ресурсов(железных) - ПК программистов слабенькие, билд серверу не хватает памяти для своего нормального функционирования и т.д. Запросы на добавление памяти(ну супер дорогой ресурс!) либо обрабатываются месяцами, либо на них забивают. И аргументы как всегда железные: «это дорого» и «сейчас нету средств».

Причем, то что я видел, это либо первый случай, либо второй. Так что бы сегодня так, а через месяц по другому практически не видел.

Появилась мысль, что нехватка оперативки и "черепаший" винчестер должны воровать не только нервы у разработчиков, но и деньги у организации. И появилась идея, прикинуть сколько это стоит? И стоит ли...? :)

Задача

Итак, условие задачи: