Введение:

Быть на первом месте в бизнесе – это не конец, а только начало битвы. Джулию Эванс и её конгломерат притесняют соперники. Недавно найденые новые технологии грозят оставить конгломерат Эвент Харайзон позади. В добавок Джулия получает мистический цветок, который содержит инопланетную ДНК, а муж Джулии и друг Грега без следа пропадает.

Мои мысли:

“Нано цветок” – третья и последняя книга в Мандел трилогии. Скажу сразу, история получилась хорошая. В особенности, если сравнивать со второй книгой! Начало резвое, стремительное, много экшена, детективной работы, загадок и тайн. Питер Хамильтон держит внимание читателя до конца, не давая расслабиться, и это великолепно. Однако, на мой вкус, “откровения” в конце не получается. Хотя опять же тут каждый смотрит со своей колокольни.

Пока я переваривал книгу, я переодически спрашивал себя: “А лучше ли она чем первая?”. Скажу точно – нет, первая книга все же лучше! Но “Нано цветок” мне очень понравился. Второй вопрос, который я задавал себе и продолжаю задавать: “Буду ли я в будущем переслушивать трилогию?”. На данный момент я точно считаю, что переслушивать не буду. Я переодически переслушиваю многие книги, но некоторые попали в черный список, например: “Павший Дракон” и Лицензия на убийство. Предполагаю, что трилогия Мандела может присоединиться к этой группе. И тут важно отметить, что мне понравились книги, однако, они не достигли моего сердца и, как следствие, у меня нет причины их переслушивать. Справедливости ради признаюсь в последний раз – детективы это не мое!

Итого:

+: Идет легко
+: История держит быстрый темп
+: Много экшена и заварушек – скучать не прийдется
+/-: Как обычно хорошая доза технологий, но поверхностно

-: Конец немного разочаровывает
=: Книга получилась отличная – много экшена, детективной работы и доза Мандела. С самого начала автор несет тебя по просторам его истории. Однако концовка на мой взгляд без кульминации.

Название: The Nano Flower
Автор: Peter F. Hamilton
Обложка:


На прошлой неделе я вынюхал, что 10-ть “избранных” программистов отправят на курсы TDD (Test Driven Development), и решил пробраться в эту десятку. К большому сожалению, я узнал немного поздновато – за пару дней, но все же решил написать емейл начальнику и посмотреть что будет. Емейл был краткий: “Не могли бы вы меня как нить засунуть на курсы TDD?” Ответ пришел день спустя – засунули!

Компания, которая проводит курсы, называется Pillar и располагается в городе Анн Арбор, что в 40 минутах езды от дома – в принципе не так плохо, но все же далековато. Сегодня был первый из двух дней курса. Прошло все отлично, конечно была пара маленьких технических заморочек, но без них ни куда! В инструкции было написано все что нужно и скажу сразу, найти парковку в Анн Арборе в рабочие дни не так уж и просто. Но компания все показала и рассказала, а потом ещё дала кредитную карту на $25 – чтобы мы “без пыли и шуму” оплатили парковку прямо рядом со зданием. Смеха ради отмечу, что парковка на рабочий день была $10. Так же из разряда других приятных мелочей, у компании Pillar есть свой шеф повар, который приготовил нам всем обед! Это не прошло мимо нашего отряда программистов. Мы сразу решили, что у нас такое тоже должно быть! И не подумайте – это вам не какие-то детские забавы, тут мы боремся с “автобусным” фактором.

От приятного к делу! Пока что курсы мне нравятся, так как меня всегда интересовала TDD. Я понимаю что и как, но всегда хотелось окунуться в это и я окунулся. Скажу, что идея однозначно интересная и даже стоящая. Однако, меня преследует какая-то странная паранойя, которую пока что не могу сформулировать! Но процесс написания программы, который начинается с теста, потом пишется код, потом пишется ещё тест и потом ещё код, а потом рефакторинг тестов и кода и так далее, пока код ни закончен – чем-то мне напомнил брутфорс (bruteforce)! Пока мы тренировались (code kata), я решил прикольнуться над своим партнером и писать тупой код – типа чтобы он тупо проходил тесты и все. И тут можно легко заключить следующее – TDD не избавляет от быдло-кода или плохого программирования. Он избавляет от других недочетов, таких как:

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

В итоге, я думаю, что TDD довольно хороший подход и использовать его нужно. Однако, что-то мне ещё не дает покоя и когда я додумаю, то, возможно, изменю свое мнение. Чирз!