Вопрос по Луркоморью графам

Вместо вступления

Как показывает практика, вот это безобразие на самом деле никого особо не волнует, и контора готова платить за плевание в потолок потери 2-3 и более часов в день. Ну и ладно - пытливый ум способен найти себе занятие (и 'освоить' офисный канал:) ).
Так вот, наткнулся я вот на этот замечательный сайт, и оказалось, что осознать всю глубину написанного мне мешает недостаточное знание русского-матерного и всяких там сленговых словечек. Благо, существует довольно подробные разъяснения практически всех непонятных слов и выражений (интересно, познавательно и с картинками).
После того, как количество закладок в браузере превысило отметку 30, родился резонный вопрос: 'А сколько же это может продолжаться?'

Более форматизированная постановка вопроса

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

Linux для разработчика

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

Итак, хочется настроить рабочее окружение для java разработки, а именно:

• JDK 6
• Ant + Maven
• Eclipse
• Увязать это все вместе и интегрировать в системму

Шаги для Windows

1. Зайти на сайт Sun Oracle, найти и скачать нужную JDK
2. Установить JDK
3. Зайти на сайт Apache, найти и скачать Ant
4. Установить Ant
5. Зайти на сайт Apache, найти и скачать Maven
6. Установить Maven
7. Пробить переменные среды (OS env)
8. Перезагрузится или закрыть все приложения и перестартовать explorer
9. Зайти на сайт eclipse.org, найти и скачать eclipse
10. Установить eclipse
11. Запустить eclipse и указать установленные JDK
12. Вытянуть нужные ярлычки

Шаги для Linux (Ubuntu)

1. Запустить synaptic
2. Найти пакеты eclipse, sun-java, ant, maven тыцнуть 'Установить' и подождать
3. Запустить eclipse и наслаждаться ?жизнью? (переменные окружения, ярлыки... вообщем все уже настроено)

Красота!

Тестирование: 3 этапа

3 этаппа:
1. Интерес
2. Пробы и понимание того, зачем это нужно
3. Уверенное владение инструментом

1. Интерес

Прочитать что такое assert() AssertionError и что такое -ea -de (параметры JVM).

2. Пробы и понимание того, зачем это нужно

Почитать книгу о рефакторинге Мартина Фаулера (и обратить внимание на главу 4). Почитать основы Test Driven Development (например вот здесь). И самое главное - побольше практики.
На этом этапе многое не понятно и практически ничего толком не получается. Самое главное 'не забросить это занятие', а продолжать и перейти на следующий этап.
Также на этом этапе придется столкнутся по крайней мере с 2 framework-ам (JUnit и JMock) и очень желательно разобраться что такое модульное/интеграционного/нагрузочное/стресс и другие виды тестирование (что это такое, зачем это нужно и характерные особенности).

3. Уверенное владение инструментом

3. Уверенное владение инструментом
В начале этого этапа приходит некая ясность в вопросах 'зачем нам это нужно', 'чего мы хотим получить' и есть 'некий практический опыт' (как правило он, этот опыт, не очень удачный и довольно карявенький :)). Так вот, на этом этапе главная цель делать все правильно и эффективно (для себя и для проекта).
Тут очень поможет мега книга - Шаблоны тестирования xUnit. Рефакторинг кода тестов. Толстая и вумная книженция, но есть подозрения, что она принесет очень не много пользы, если не пройти первый и второй этапы.

Мысль о Research Reports

Мысль навеяна воспоминаем одного друга о прошлой работе и кое какими событиями на текущей...

Вопрос

Насколько эффективно выполняются research задачи?

Небольшое пояснение

Оставим случаи 'пойди туда, не знаю куда', а рассмотрим какую нибудь простенькую задачку, с внятной целью.
Ну например: 'научится маппить связь один-многие в Hibernate'.
Под эффективностью я имею ввиду не численный показатель, а меня интересует вот что:
Допустим задание было дано человеку, который не знает что такое 'связь один-многие'. Этот самый человек скорее всего сделает следующее:

• сначала почитает что такое one-to-many, заодно и все остальные виды связей;
• потом он найдет документацию, и прочитает какую аннотацию поставить или что прописать в файл маппинга;
• затем (если по хорошему) он попробует сделать небольной примерчик, а может даже найдет какой нить hibernate tutorial.

В итоге мы получаем 3 момента:

• человек потратил примерно день на исследование;
• формально, результатом этого исследования является всего лишь одна строка кода (аннотация)
• все остальные добытые знания, в лучшем случае останутся в голове у исследователя

Есть еще неявный четвертый пункт - если этого человека не будет 'под рукой', а понадобится, ну скажем замаппить many-to-many, в этом случае второй 'исследователь №2' проделает почти такой же путь.

Что не нравится

CXF: Шаг 1 - Описание интерфейса средствами Java

Шаг 1. Описание интерфейса средствами Java.
На мой взгляд, работая с CXF лучше использовать именно 'Java first' схему объявления интерфейса. В основном потому, что манипулируя аннотациями легче получить желаемый WSDL.
Итак, процесс описания интерфейса веб сервиса предельно прост и довольно подробно описан на сайте CXF. Но встречаются мелкие моменты, которые не описаны толком, но при этом не дают спать спокойно.

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

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

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

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

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

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

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