avl

Оригинал лежит вот тут: 97 Things Every Software Architect Should Know

1. Ваше резюме не должно быть на первом месте
2. Сложное - упрощайте, с усложнением - боритесь!
3. Скорее всего, ваша главная пробема - не техническая
4. Коммуникация - это король, а ясность и лидерство - его покорные слуги
5. Баланс между техническими требованиями и интересами участников
6. Ищите настоящую причину требований
7. Встаньте!
8. Небоскребы не масштабируются!
9. Вы участвуете в переговорах чаще, чем вы думаете
10. Количество имеет значение!
11. Строка работающего кода ценнее, чем 500 строк спецификации
12. Универсальных решений не существует!
13. Никогда не рано задуматься о производительности
14. Архитектура определяет производительность
15. Коммит без проверки - убийца производительности
16. Однообразия может и не быть
17. Бизнес управляет
18. Простота лучше универсальности
19. Архитектор должен быть практиком
20. Непрерывная интеграция
21. Избегайте неудач планирования
22. Все сразу получить невозможно
23. База данных - ваша крепость
24. Используйте неопределенность как мотиватор
25. Расширение границ проекта - враг успеха

Текст оригиналов выложен под лицензией Creative Commons Attribution 3. C переводами можете поступать так же :)

Продолжение в ближайшем будущем, примерно по 1 главе в день :)

Очень многие, так или иначе связанные с ИТ, не раз слышали такую фразу: "Если бы строители строили дома так, как программисты пишут программы, то первый же залетевший дятел разрушил бы цивилизацию". И хотя с таким положением вещей сложно не согласиться, лично мне такое положение вещей не нравится.

А почему оно такое, и что с этим можно сделать?

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

Для кого этот тренинг?

Если ваш проект трещит по швам, если перенос сроков стал уже привычным, если вы терпеть не можете спецификации и не понимаете, зачем вам нужны верификаторы, потому что ошибки плодятся быстрее, чем выявляются - то этот тренинг для вас.

Если вы еще только начинаете свою карьеру программиста, и в растерянности от того, что в жизни все не так, как в ВУЗе или книгах, то участвуйте не задумываясь!

Если вы хотите получить работающую модель эффективной разработки, где все стоит на своих местах, а сам проект всегда под контролем, если вы не хотите изобретать ИТ-велосипед, а хотите использовать проверенные временем и практикой решения - то всего лишь через одну неделю участия в этом тренинге вы это получите. И даже сами попробуете осуществить все те техники, предназначенные для облегчения нелегкого труда программиста.

"Результаты. Начал-таки пользоваться багтрекингом. Думаю, скоро и до SVN доберусь (пока только поставил, но в рабочий процесс не внедрил). Спецификации писал и раньше, риски тоже всегда старался оценивать." - такой отзыв оставил участник с ником sukebe

"Тот случай когда я получил целостное видение картины, курс получился с одной стороны не достаточно объемным, а с другой охватил все темы" - отзыв о тренинге от участника с ником hakzzz

"Результаты: систематизировал для себя знания о предмете" - так отозвался о тренинге участник с ником Cruncher.

Вам не нужно приходить на тренинг, если:

• словосочетание "Управление рисками" для вас не пустой звук, а повседневная практика;
  
• вы в любой момент времени можете назвать наиболее вероятную дату окончания проекта, и проект действительно завершится к этой дате;
  
• у вас уже есть отлаженная связка системы контроля версий и системы трекинга ошибок, и вся ваша команда прекрасно этой связкой пользуется;
  
• вы никогда не ошибаетесь и у вас за спиной прорезываются крылышки .
  

Когда и где будет проходить тренинг?

Тренинг стартует 5-го октября 2009 года и будет длиться семь дней. Проводиться он будет в виде web-кастов (онлайн радиовещания) минут по 30-40 в день с моментальной обратной связью через чат. Кроме этого, участникам нужно будет каждый день проводить самостоятельную работу - небольшие домашние задания по 1-2 часа в день.

Начало кастов в 21:00 по московскому времени. Проходить это все будет на площадке webinar2.ru вот на этой страничке. Для участия необходимо зарегистрироваться.


На данный момент онлайн-тренинг проведен и зафинален. Материалы тренинга теперь доступны в виде "виртуальной коробки".

Виртуальная коробка

В "виртуальную коробку" войдет следующее:

• все аудиокасты основного тренинга, включая ответы на вопросы участников и бонусы;
  
• сильно усовершенствованная методичка, с более детальным описанием материала, домашними заданиями, новыми темами, не вошедшими в основной тренинг;
  
• миникнига по основам UML (c рассмотрением использования UML диаграмм на живом примере проектирования)
  

Но это еще не все! Кроме всей этой ценной информации будут еще и бонусы!

Итак, первый бонус, любезно предоставленный Евгением Воротниковым, автором тренинга "Ленивая разработка":

• аудиокаст на темы "Как обмениваться скиллами или принципы непрерывного обучения" и "Как организовывать конструктивные проектные совещания"
  
• аудиокаст на тему "Как решить проблему 'тяжелой архитектуры' с помощью методики 'матрица сценирования'"
  

Второй бонус предоставлен Кирой Сорокиной, автором тренинга "Старт работы техническим писателем за 7 дней". Бонус состоит из двух частей: аудиокаста на тему "Введение в систему ГОСТов 34 группы для тех, кто взаимодействует с госзаказчиком" и еще одного аудиокаста на тему "Самомотивация для технических писателей". Бонус безусловно будет полезен всем, кому приходится сталкиваться с работой технического писателя. А так или иначе с этим сталкивается практически каждый программист :)

А третий бонус позволит вам немного "заглянуть за кулисы" и посмотреть на то, как велась подготовка к этому тренингу. Бонус от Фарита Насипова, автора многих тренингов по 1С, автоматизации и другим подобным вещам, активно помогавшего своей команде подготовить и провести свои тренинги в рамках ФМ6. Фарит разрешил в качестве бонуса дать свои аудиокасты на тему "Написание миникниги". Если вы хотя бы раз задумывались, как лучше всего сообщить большому количеству людей о какой-нибудь теме, в которой вы чувствуете себя экспертом - то миникнига является одним из таких способов!

И еще один бонус при покупке тренинга - месяц участия в матер-группе бесплатно! Для наиболее эффективной работы с полученной на тренинге новой для вас информацией вам очень поможет обратная связь, возможность задать вопрос и получить на него ответ. Именно для этого и служит мастер-группа. И именно поэтому я каждому купившему основной тренинг подарю еще и месяц мастер-группы - возможности задать лично мне как автору вопрос и получить на него ответ в прямом эфире.

Цели и задачи тренинга

Итак, что же вы получите, купив этот тренинг?

Цель тренинга следующая: "Рассмотреть основные элементы эффективной системы разработки программного обеспечения и управления проектами и попробовать применить это все в реальной жизни". Ключевое слово здесь "попробовать". Информации - много, реальной практики - увы, мало. Тренинг будет ориентирован на активную работу участников. Которая обернется значительно более весомыми результатами, чем от простого прочтения книги или статьи.

( подробный план по дням )

Сколько этот тренинг будет стоить?

Вы не поверите - АБСОЛЮТНО БЕСПЛАТНО!

Онлайн-тренинг действительно был бесплатным для всех желающих, успевших в него записаться до 5-го октября. Теперь же материалы тренинга доступны за весьма небольшие деньги - эквивалент 30 евро в любой валюте :)


Тем, кто решит оплатить материалы тренинга до начала продажи - 1-го ноября, суперскидка 50%. Т.е. вам тренинг обойдется лишь в 15 евро!


К сожалению, время действиия скидки закончилось, и теперь тренинг стоит свою полную цену: 30 евро.

У вас может возникнуть вполне закономерный вопрос: "Зачем мне платить деньги за информацию, которая и так доступна в интернете?". И я постараюсь на него ответить. Конечно, вы можете не платить. Более того, я даже оставил в открытом доступе все домашние задания онлайн-тренинга (просмотреть их вы можете по вот этой ссылке). Но в этом случае вас будет поджидать одна маленькая опасность - вы ничего не сделаете. Вы может даже и зайдете по указанной выше ссылке посмотреть на домашние задания, но вот шансы того, что вы их сделаете, будут практически равны нулю.

И для того, чтобы добавить вам заинтересованности в результате, я и ввожу необходимость заплатить небольшую сумму денег за тренинг. Тем самым я сильно повышаю ваши шансы на получение результата. В конце концов, вероятность того, что после прохождения тренинга и выполнения всех заданий вы сможете адекватно объяснить своему руководству необходимость повысить вам зарплату, и вам ее действительно повысят, очень высока. Стоит заплатить один раз 30 евро, чтобы обеспечить повышение зарплаты, или не стоит - решать вам.

Если вы опасаетесь, что это кидалово, то спешу вас заверить, вы ничем не рискуете! Если вы в течении года после покупки решите, что вам не нравится то, что вы получили, я верну вам всю сумму денег (за исключением комиссиии платежной системы - 0.8%). Без каких-либо объяснений. Единственное ограничение - в этом случае для вас будет недоступно участие во всех остальных моих проектах и тренингах.

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

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

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

Скачать обзорный аудио-каст прямо сейчас!

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

PPS. А также можете прочитать мою небольшую статью "Десять проблем в ИТ разработке" , она тоже даст вам понять, о чем будет идти речь на моем тренинге.

Как оплатить?

Оплатить материалы тренинга вы можете при помощи системы WebMonew, переведя сумму, эквивалентную 30 евро на один из кошельков:

1. E336423455598
   
2. Z411344457036
   
3. R422000711807
   
4. U149896408558
   

После чего написать мне письмо на avl-kharkov@yandex.ru. На этот же адрес пишите, если у вас есть какие-нибудь вопросы или неясности.

Если вы не использовали систему WebMoney ранее, то найти информацию, как с ее помощью делать платежи, например, в рублях, можно вот тут.

Мастер-группа

В дополнение к этому тренингу, одновременно с началом его продаж, я открываю мастер-группу.

Что это такое?

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

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

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

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

Для более широкого и глубокого рассмотрения вещей как раз и будет предназначена мастер-группа.

Стоимость участия в мастер-группе - 20 евро в месяц.

Проводиться мастер-группа будет начиная от одного участника! Т.е. даже если участие оплатит лишь один человек, прямой эфир состоится. И этот один человек получит практически индивидуальную работу, индивидуальный коучинг! Вы где-нибудь видели еще возможность индивидуальной работы за такую сумму? Так что спешите не упустить шанс стать первым!

Подарок!

Всем купившим материалы тренинга - подарок! Первый месяц мастер-группы бесплатно!

Не упустите это предложение!

В гонке со временем время никогда не проигрывает! :)

(В оригинале - Scope is the enemy of success)

Границы проекта определяют его размер. Сколько времени, усилий и ресурсов потребуется? Какая функциональность и какого уровня качества? Насколько сложно это будет внедрить? Какой риск? Какие ограничения? Ответы на эти вопросы и определяют границы проекта. Проектировщикам нравятся большие, сложные проекты. Потенциальная награда за сложный проект может подталкивать людей искусственно раздвигать границы проекта для повышения видимой важности. Раздвигание границ – враг проекта, потому что при этом вероятность провала растет быстрее ожидаемого. Увеличение проекта вдвое может повысить вероятность провала на порядок.

Почему это работает именно так? Давайте рассмотрим несколько примеров.

• Интуиция нам подсказывает удвоить время или ресурсы при удвоении объема работы. История же говорит ("The Mythical Man-Month" by Fred Brooks), что зависимость здесь нелинейная. К примеру, команда из четырех человек потратит более чем в два раза времени на коммуникацию, чем команда из двух человек.
  
• Оценки оказываются далеки от реальности. Кто ни разу не сталкивался с вещами, реализовать которые оказывалось значительно сложнее, чем ожидалось?
  

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

• Понимание реальных потребностей. Проект должен содержать то, что перечислено в требованиях. Требования определяют функциональность и ее качество. Если требование не объяснено в терминах измеряемой ценности для заказчика, то это повод задавать вопросы. Если требование не приносит заказчику прибыли, зачем оно вообще нужно?
  
• Разделяй и властвуй. Ищите возможности разделить проект на несколько независимых частей. Гораздо легче управлять несколькими маленькими проектами, чем одним большим.
  
• Приоритет. Мир бизнеса изменчивый. Требования к большому проекту могут поменяться несколько ко времени его окончания. Важные требования обычно остаются важными и при изменении в мире бизнеса, а остальные могут измениться или даже совсем исчезнуть. Приоритизация позволит вам выпустить наиболее важные вещи в первом релизе.
  
• Выпуск результата как можно ранее. Очень мало людей точно знают, что именно они хотят до того, как это получат. Наверняка вы видели известную картинку, показывающую эволюцию проекта детских качелей, и помните разницу между тем, что хотел заказчик, и что было сделано реально. Переусложненный результат напоминал качели очень отдаленно, а последний кадр «что на самом деле хотел заказчик» показывает самую простую качелю из старой автомобильной шины. Если заказчик получит возможность что-то попробовать, решение может оказаться сильно проще первоначально ожидаемого. Реализация наиболее важных вещей в первую очередь даст вам важную обратную связь раньше, когда она вам больше всего и нужна.
  

Сторонники agile разработки ("eXtreme Programming eXplained" by Kent Beck) советуют реализовывать «самый простой вариант, который еще работает». Сложная архитектура проваливается значительно чаще, чем простая. Уменьшение границ проекта часто приводит к более простой архитектуре. Уменьшение границ – одна из эффективных стратегий для архитекта на пути повышения вероятности успеха.

Автор оригинала - Dave Quick

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Use uncertainty as a driver)

Оказавшись перед выбором из двух альтернатив, большинство думает, что главное – это сделать правильный выбор между ними. В проектировании (ПО и не только) это не так. Наличие двух возможностей – индикатор того, что вам нужно подумать о внесении неопределенности в дизайн. Используйте неопределенность как повод определить, где вы можете отложить принятие решения, или где вы можете снизить значимость этого выбора. Если вы привяжете себя к первому пришедшему в голову варианту, скорее всего, поменять его потом будет сложно, в результате случайный выбор станет значимым и гибкость продукта снизится.

Одно из самых простых и конструктивных определений архитектуры дал Гради Буч: «Вся архитектура – это дизайн, но весь дизайн – это не архитектура. Архитектура представляет значимые решения дизайна, формирующие систему, где значимость измеряется стоимостью изменения». Что из этого следует – это то, что эффективная архитектура должна снижать значимость решений. Неэффективная же архитектура значимость усиливает.

Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное – не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не всегда будет окончательным).

Архитектор должен пройти огонь и воду, чтобы научиться легко видеть дихотомию. Стояние у доски и энергичное обсуждение вариантов с коллегами? Пыхтение над кодом и размышление, попробовать ту или эту реализацию? Когда новое требование или уточнение старого перечеркивает текущую реализацию, это проявление неопределенности. Ответ на это – найти такую инкапсуляцию, которая могла бы изолировать решение от кода, сильно зависящего от этого решения. Без этого умения видеть ответ часто заключается во внесении хаотичных изменений в код и попытках компенсировать неопределенность множественными универсальными опциями. Или же, если решение принимается случайно, результатом может оказаться поворот в неправильном направлении.

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

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

Автор оригинала - Kevlin Henney

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Database as a Fortress)

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

Распространенность agile технологий разработки сделало массовой мысль о том, что проектирование в процессе разработки – это нормально или даже хорошо. В прошлом остались времена написания сложных всеобъемлющих спецификаций. Новая школа учит выпускать версии быстро и часто. Строка кода в релизе лучше десяти в вашей голове. Все это выглядит слишком хорошо, чтобы быть правдой, и в том месте, где начинаются ваши данные, именно так и есть.

Если бизнес-логика и интерфейс пользователя действительно часто эволюционируют, то структуры данных и связи между ними этого не делают. Поэтому очень важно иметь правильную модель данных с самого начала, как со структурной точки зрения, так и с аналитической. Миграция с одной схемы на другую в лучшем случае – сложная задача, всегда требующая много времени и часто склонная к внесению ошибок. Если с ошибками на уровне приложения некоторое время вполне можно жить, то ошибки на уровне базы данных могут стать катастрофой. Обнаружение и исправление проблемы дизайна на уровне базы данных не вернет вам потерянных или поврежденных данных назад.

Целостная модель данных – это то, что обеспечивает вам сохранность данных сегодня и расширяемость завтра. Обеспечение сохранности подразумевает устойчивость к ошибкам, которые, несмотря на все ваши усилия, будут возникать в часто меняющемся уровне приложения. Это означает обеспечение ссылочной целостности. А также построение доменозависимых правил и ограничений везде, где это возможно. Это означает выбор ключей, помогающих вам убедиться в ссылочной целостности и соответствии установленным правилам. Быть готовым к расширению завтра означает правильным образом нормализовать данные, чтобы потом легко надстраивать уровни над моделью данных. Это означает не искать коротких путей.

База данных должна быть последним привратником, охраняющим ваши ценные данные. Приложение, могущее меняться ежедневно, не может быть сторожем даже для самого себя. Чтобы база данных могла играть эту роль, модель данных должна быть спроектирована так, чтобы не принимать изначально неправильные данные и предотвращать не имеющие смысла отношения. Ключи, внешние отношения, правила и ограничения, описывающие схему – это лаконичные, понятные и легко проверяемые вещи, к тому же отлично самодокументируемые. Правила, задающие модель данных, к тому же достаточно стабильные, и изменения уровня приложений часто оставляет их без изменений.

Чтобы использовать возможности реляционной базы данных на все сто – сделать ее полноценной частью приложения вместо простого хранилища данных, вам нужно с самого начала представлять, что вы делаете. Когда ваш продукт будет эволюционировать, то вместе с ним будет меняться и уровень данных. Однако на каждом шагу своей эволюции база данных должна оставаться крепостью. Если вы доверите и делегируете ответственность за обнаружение ошибок в остальных уровнях приложения вашей базе данных, вы в этом не разочаруетесь.

Автор оригинала - Dan Chak

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Architectural Tradeoffs)

Каждый проектировщик ПО должен понимать, что невозможно сделать все и сразу. Невозможно разработать архитектуру, которая была бы высокопроизводительной, стабильной, безопасной и с высокой степенью абстракции на всех уровнях. Есть один реальный пример, знать который рекомендуется каждому архитектору. Это история корабля Васа.

В 1620-м году шла война между Швецией и Польшей. Желая побыстрее завершить эту разорительную войну, шведский король начал строительство корабля, названного Васа. Это должен был быть не простой корабль. Требования к нему были уникальными для того времени. Он должен был быть более 60 метров в длину, нести 64 пушки на двух оружейных палубах, и иметь возможность перевозить 300 солдат на борту. Сроки были критичны, денег было мало (звучит знакомо, не так ли? :) Дизайнер корабля никогда до этого не проектировал корабли такого класса. Он был экспертом в постройке кораблей меньшего класса, однопалубных. Тем не менее, он экстраполировал свой предыдущий опыт и спроектировал Васа. Корабль был успешно построен по его спецификациям, и в день запуска корабль гордо вышел в гавань, отсалютовал из своих пушек и практически сразу же затонул.

Проблема корабля оказалась тривиальной – палуба боевых кораблей тех лет была обычно тесным и опасным местом, особенно в бою. Постройка же корабля, одновременно являющегося и боевым, и транспортным, оказалась дорогой ошибкой. Архитектор, желая удовлетворить желания короля, построил слишком неустойчивый корабль.

удовлетворить все требования может привести к нестабильной архитектуре и как следствие, неудовлетворительной реализации всех требований. Хорошим примером может быть требование создать серверную архитектуру, хорошо работающую и для случаев «точка-точка». Чтобы сделать такое, вам придется серьезно нарушать уровни абстракций, созданные для серверной версии, приводя к тому, что архитектура становится похожей на одно из блюд итальянского ресторана. Существует несколько инструментов, позволяющих определить и выявить альтернативы при разработке архитектуры. Две популярные методологии, делающие это - Architecture Tradeoff Analysis Method (ATAM) и Cost Benefit Analysis Method (CBAM). Подробнее про эти методологии можно почитать на сайте Software Engineering Institute здесь и здесь.

Автор оригинала - Mark Richards

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Avoid Scheduling Failures)

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

Идея, что сроки можно ужать, для того чтобы снизить расходы или ускорить выпуск, часто приходит в головы. Однако ничего хорошего из этого не получается. Обычно для того, чтобы уложиться в новые сроки, прибегают к переработкам или же жертвуют «маловажными вещами», такими как юнит-тестирование, например. Избегайте этого сценария любой ценой. Напомните тем, кто захочет пойти по этому пути, что:

1. Поспешное проектирование ведет к низкому качеству дизайна, ужасной документации и возможным проблемам на стадии верификации или принятия заказчиком;
   
2. Чем более поспешно пишется код, тем больше ошибок оказывается в финальной версии у заказчика;
   
3. Поспешное тестирование приводит к недостаточно протестированному коду и невыявленным проблемам;
   
4. Все вышесказанное приводит к ошибкам, выявленным у заказчика «в поле», исправление которых обходится намного дороже.
   

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

Как архитектор вы наверняка однажды обнаружите себя в ситуации, требующей немедленного вашего вмешательства, чтобы повысить вероятность успешного завершения. Действуйте сразу и быстро. В первую очередь попытайтесь сохранить качество, отстаивая первоначальные сроки. Если же сокращения сроков избежать не удается, тогда пытайтесь перенести некритичную функциональность в следующий релиз. Обычно для этого требуется хорошая предварительная подготовка, мастерство ведения переговоров и умение влиять на людей. Готовьтесь к этому, заранее оттачивая эти умения, начинайте прямо сейчас. Когда-нибудь вы это очень сильно оцените.

Автор оригинала - Norman Carnovale

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Continuously Integrate)

Разработка по методу «Большого взрыва» способна убить практически любой проект. Проектировщик должен инициировать и поддерживать использование методов и инструментов непрерывной интеграции для любого проекта.

Термин «Непрерывная интеграция» (Continuous Integration) впервые был введен в обращение Мартином Фоулером (Martin Fowler). Непрерывная интеграция представляет собой набор практик и инструментов, обеспечивающих автоматическую сборку и тестирование приложения с небольшими интервалами, обычно на специальном выделенном для интеграции сервере. Связь практики юнит-тестирования и автоматической сборки делают непрерывную интеграцию обязательным для применения на любом современном проекте.

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

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

Непрерывная интеграция обеспечивает большую стабильность и приводит к повышению эффективности. Как архитектор вы несомненно полюбите этот процесс, но более важно то, что ваша организация и ваша команда разработки станут более эффективными.

Автор оригинала - Dave Bartlett

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

Успели захватить золотую осень, вместо слов пусть будут фотки :)



( Посмотреть остальные 19 фото )

Все фото вообще без обработки (и без экстремальных установок насыщености цвета в фотоаппарате). Фотоаппарат конечно радует тем, что фотки получаются такими, что их практически не надо обрабатывать!

Много раз проезжал мимо, и вот однажды не удержался и взял с собой фотоаппарат.

Первый кадр - прямо из окна дома.

( Вид из окна )

А это - минутах в пяти езды от дома.

( Осеннее-1 )

( Осеннее-2 )

( Осеннее-3 )

Да, для тех, кто из Словении, маршрут на работу - это Drulovka (Kranj) - Mavčiče - Ljubljana, а фотки сделаны в населенном пункте Jama.

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

Однако результат оказался не совсем таким, каким планировался...

( Домик из пряников после запекания )

Уже потом я вспомнил фразу в инструкции: "Если пряничные коржи стали слишком твердыми, разогрейте их в духовке в течении 10-15 минут" :)

Так что инструкцию порой надо читать внимательно и не нарушать :))

Ребенок сидел, игрался с буквами, а потом радостно прибежал, держа в руках три буквы, соединенные друг с другом :)

( Посмотреть :) )

(В оригинале Architects must be hands on)

Хороший архитектор должен быть практиком. Он должен быть способным занять любую позицию в команде, начиная от прокладки сети и конфигурации процесса сборки до написания юнит-тестов и измерения производительности. Без глубокого понимания всего диапазона технологий архитектор ничем не отличается от обычного менеджера проекта. Конечно же, люди в команде могут иметь более глубокие знания тех или иных технологий в своих областях, но при этом очень сложно представить, как они смогут доверять архитектору, если он вообще не разбирается в технологии. Как уже было сказано, архитектор – это интерфейс между бизнесом и разработкой, и поэтому он должен понимать все аспекты разработки, чтобы адекватно представить все возможности для заказчика, не прибегая к постоянным консультациям остальных. Аналогично, архитектор должен понимать язык заказчика, чтобы вести команду к целям, поставленным заказчиком.

Архитектор – как первый пилот самолета. Он может не выглядеть слишком занятым постоянно, однако он непрерывно использует десятилетия опыта для оценки ситуации и всегда готов предпринять нужные шаги, если он увидит или услышит что-то экстраординарное. Менеджер проекта (второй пилот по этой аналогии) выполняет ежедневные управленческие задачи, освобождая архитектора от загрузки рутиной и управления людьми. В конце концов, именно архитектор должен нести ответственность за выпуск и качество продукта. И этого трудно ожидать, если архитектор не имеет авторитета в команде.

Люди лучше всего обучаются, смотря на других. Именно так мы учились в детстве. Хороший архитектор должен быть способным обнаружить проблему, собрать команду вместе и без поиска виноватых объяснить, в чем проблема может быть, и предложить элегантное решение. Абсолютно нормально при этом обратиться за помощью к команде. Команда должна ощущать себя частью решения, но при этом архитектор должен управлять дискуссией и выбирать правильные решения.

Архитектор должен быть добавлен в команду в самом начале проекта. Он не должен сидеть на академических высотах, диктуя направления, а вместо этого должен приземленно работать вместе с командой. Вопросы вроде «В каком направлении двигаться» или «Какую технологию выбрать» не должны выливаться в новые исследования или проекты, вместо этого ответы должны выбираться исходя из практического опыта или при помощи совета от других архитекторов-коллег (ведь у хорошего архитектора всегда будут связи с другими хорошими архитекторами!).

Хороший архитектор должен быть экспертом в использовании хотя бы одного инструмента, например, IDE. Логично ожидать, что проектировщик ПО должен знать IDE, проектировщик баз данных – средства моделирования баз данных, а информационный проектировщик – инструменты XML. Однако технический архитектор должен знать хотя бы минимально все инструменты от мониторинга сети (Wireshark) до моделирования сложных финансовых сообщений (XMLSpy) – ни один уровень тут не будет ни слишком высоким, ни слишком низким.

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

Автор оригинала - John Davies

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Simplicity before generality, use before reuse)

Общая проблема различных компонент, библиотек классов, базовых сервисов и других подобных глобальных решений в том, что большинство из них разрабатывалось «вообще», без привязки к конкретным приложениям. Это приводит к огромному количетсву опций и возможностей, часто остающихся неиспользуемыми, используемыми не по назначению или же вообще никому не нужными. Большинство разработчиков работают на конкретных системах, и неограниченная универсальность очень редко оказывается для них полезной. Лучший способ придти к универсальности – через понимание известных, конкретных примеров и фокус на их сути, чтобы выделить реальную общность. Простота через опыт вместо общности через предположения.

Отдание предпочтения простоте перед универсальностью может стать тем фактором, который склонит чашу весов при прочих равных условиях. Если у вас есть два возможных решения, отдавайте предпочтение более простому и основанному на конкретных необходимостях вместо запутанного и декларирующего универсальность. Скорее всего, более простое решение окажется достаточно универсальным на практике. И если даже в результате окажется, что таки нужно использовать более универсальное решение, то поменять простое решение на более сложное, понимая, зачем и почему это надо, будет намного проще, чем обнаружить, что универсальное решение оказалось недостаточно универсальным в нужном вам контексте.

Также часто случается, что разработанное решение «для всего сразу» в реальности оказывается не пригодным «ни для чего конкретного». Компоненты ПО должны в первую очередь разрабатываться для конкретных целей и удовлетворять именно эти цели. Эффективная универсализация следует лишь из глубокого понимания, которое в свою очередь, приводит к упрощению. Такая универсализация может позволить упростить задачу до более базовой, основываясь на анализе известных примеров и выделении общих для них концепций. Универсальность, которая четко выражена, лаконична и обоснована. Однако часто универсализация становится вещью в себе, уводя проект в противоположном направлении и добавляя сложность вместо ее уменьшения. Погоня за таким обобщением часто приводит к решениям, никак не привязанным к реальности разработки. Такое обобщение оказывается основанным на предположении, которое позже оказывается неверным, предлагает варианты, которые никогда не понадобятся, накапливает «багаж», который невозможно выбросить, и таким образом добавляя излишнюю усложненность, с которой приходится иметь дело будущим разработчикам и архитекторам.

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

Автор оригинала - Kevlin Henney

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Business Drives)

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

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

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

Разработка ПО – это в основном проектирование, включающее в себя постоянное принятие решений вплоть до запуска продукта в эксплуатацию. Разработчики могут принимать многие из этих решений, но они ни в коем случае не должны принимать решения, касающиеся интересов заказчика. Однако как следствие того, что заказчики часто не готовы брать на себя ответственность, предоставляя направление разработки, эти решения часто перекладываются на разработчиков. Архитектор должен обеспечить макро-контекст для всех микро-решений на уровне разработки, при этом защищая архитектуру и цели заказчика и следя за тем, чтобы разработчики не принимали решений в зоне ответственности заказчика. Технические решения, не привязанные к тем обязательствам, ожиданиям и реальностям бизнеса, которые должен все время озвучивать заказчик, приводят к неоправданому расходу дефицитных ресурсов.

Долгосрочные интересы разработки лучше всего соблюдаются, если процессом управляет заказчик.

Автор оригинала - Dave Muirhead.

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале There Can be More than One)

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

В технических областях мы все можем привести к одинаковости. Для нас – очень удобно. Однако бизнес имеет дело с неупорядоченным, множественным, запутанным и неопределенным миром. Более того, бизнес имеет дело даже не с «миром», а с мнениями людей о том или ином аспекте этого мира. Одно из решений – считать, что мы имеем дело с технической областью, и принудительно применить универсальное решение. Однако реальность – такая штука, которая продолжает существовать, даже если вы не верите в нее. И сложность все равно появляется по мере эволюции бизнеса. В результате появляются энтерпрайз команды, тратящие свое очень недешевое время на попытки побороть страхи разговорами о DTD. А заказчики, оплачивающие это, склоняются в результате к тому, что получаемый результат далек от совершенства.

Почему же не принять реальность этого беспорядочного мира и не разрешить множественные, противоречивые, пересекающиеся представления, сервисы и решения? С технической точки зрения это может звучать просто ужасно. Только представьте: несогласующиеся обновления, перерасход ресурсов на техподдержку, зависимости, напоминающие тарелку со спагетти, которые надо держать под контролем, и прочие подобные вещи. Однако давайте посмотрим на пример из мира информационных хранилищ. Схемы данных часто ненормализованы, исходные и вычисленные данные смешиваются друг с другом, структуры данных и представляющих и таблиц сильно различаются. И небеса не падают. ETL процесс находится на границе двух различных миров, транзакций и анализа. Эти миры различаются частотой изменения, пропускной способностью, частотой изменения дизайна и возможно также сильно отличаются в объеме. И это здесь – ключевой момент: сильно отличающиеся нефункциональные свойства подсистемы создают границу, на которой и становится возможным управлять противоречивыми представлениями.

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

Автор оригинала -

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале Commit-and-run is a crime.

Вторая половина дня. Команда дописывает последние фрагменты новой функциональности очередной итерации, и вы буквально слышите, как кипит работа. Однако Джон сегодня слегка спешит. Он уже опаздывает со своей задачей, однако планирует сегодня закончить. Он набирает код, компилирует его, помещает в систему контроля версий и убегает. А еще через несколько минут все рушится. Билд в нерабочем состоянии. У Джона не было времени запустить автоматические тесты перед помещением своего кода, поэтому он поместил его просто так, без проверки. И тем самым подвесил весь проект. Работа, кипевшая еще несколько минут назад, начинает остывать. Каждый понимает, что если он сейчас сделает uplate из системы контроля, то его локальная копия тоже станет нерабочей. Однако без этого он не может опубликовать свои изменения. А поскольку именно сегодня вечером всей команде нужно интегрировать свои наработки для выпуска предстоящей демо-версии, то ситуация весьма неприятная. Джон очень эффективно убил производительность всей команды, потому что интеграция стала невозможной без необходимости отменить все его изменения.

Такой сценарий происходит достаточно часто. Коммит без проверки – преступление, потому что убивает поток. Очень часто один разработчик, желая сэкономить свое время, вызывает потерю времени всей команды, и это весьма неучтиво. Однако, это происходит практически везде. Почему? Обычно потому, что правильный цикл сборки и тестирования занимает слишком много времени.

И здесь вам, как архитектору, нужно вступать в игру. Если вы постараетесь создать гибкую архитектуру, обучите людей agile-практикам, к примеру, разработке через тестирование, настроите интеграционный сервер, то тем самым вы воспитаете культуру, в которой не будет правильным тратить чье-либо время впустую. Чтобы это стало реальным, вы должны быть уверены, что система, кроме всего прочего, имеет подходящую для автоматизированного тестирования архитектуру. Это изменит поведение разработчиков. Если тесты будут выполняться быстро, то их будут запускать чаще, что хорошо уже само по себе, однако главное – это то, что разработчики не будут оставаться наедине с испорченным кодом. Если тесты зависят от внешних систем, если требуется база данных, то измените их так, чтобы их можно было запускать локально с использованием симуляторов или заглушек, или хотя бы с использованием локальной копии базы данных, и пусть тесты выполняются автоматически. Люди не должны ждать, потому что в противном случае они будут придумывать обходные пути, что часто приводит к описанным выше проблемам.

Инвестируйте время в создание систем, которые будут работать быстро. Это ускоряет весь поток, делая разработку более быстрой. Используйте симуляторы, уменьшайте зависимости, разбивайте систему на маленькие модули – делайте то, что считаете нужным. Главное – обеспечьте, чтобы у людей не было причин даже думать о том, чтобы сделать коммит без проверки.

Автор оригинала - Niclas Nilsson

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

Этим летом неделю пожили в термах Зрече (http://www.terme-zrece.si/cgi-bin/cms.cgi?doc=10005)

С Олимией конечно не сравнить (если сравнивать бассейны), но в целом очень неплохо, особенно если учесть самую низкую в Словении цену - 300 евро за неделю апартментов на трех человек)

Из плюсов - красивые окрестности. Вот такой вид буквально в паре минут ходьбы от апартмента.



А вот так выглядят сами апартменты.

( Апартмент в сосновом лесу )

С вот таким вот видом из окна:

( Вид из окна апартмента )

А вот так выглядит основной бассейн под крышей.

( Основной бассейн )

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

Наружный бассейн с горками (которые включали только по выходным)

( Наружный бассейн )

Озеро, находящееся неподалеку, освещается ночью фонарями.

( Озеро в сумерках )

А в получасе езды по не очень сложному серпантину - Рогла с прикольным летним санным спуском.

Вид с террасы ресторанчика неподалеку (на заднем плане виден старт санного спуска):

( Рогла )

В целом - приятное и спокойное место, есть где побегать детям, домики в сосновом лесу, близость озера (где за небольшие деньги можно половить рыбу) и час езды от Любляны. Цены невысокие, вокруг полно вкусных и недорогих ресторанчиков. Близость горнолыжного курорта (термы работают и зимой). Не такой большой выбор водных развлечений, как в той же Олимии, но для спокойного семейного отдыха - очень неплохо.

И еще там большое предложение романтических двухместных отдельностоящих ванн с соответствующей атрибутикой - шампанское, свечи, но мы туда не ходили.

(В оригинале - Application architecture determines application performance)

Архитектура приложения определяет его производительность. Это утверждение кажется очень простым и очевидным, однако мировая практика показывает, что это не так. Например, проектировщики ПО часто верят в то, что для значительного прироста производительности достаточно простого перехода от одного бренда производителя к другому. Эта вера может быть вызвана разрекламированными результатами измерения производительности от вендора, обещающими, к примеру, на 25% лучшую производительность по сравнению с конкурентами. Но на самом деле, если к примеру продукт данного вендора выполняет одну операцию за 3 миллисекунды, а продукт конкурента – за 4 миллисекунды, то этот 25% выигрыш производительности (1 миллисекунда!) окажет очень несущественное влияние на конечную производительность всей системы, особенно если в проблемы производительности находятся в корне архитектуры системы.

В дополнение к руководителям ИТ и командам измерения производительности различных вендоров, другие люди – техподдержка вендоров и авторы книг по оптимизации производительности – часто рекомендуют лишь «тонкую настройку» инфраструктуры ПО, ограничивающуюся распределением памяти, размерами буферов и тому подобными вещами. Но если приложение спроектировано неподходящим для ожидаемой нагрузки образом, или же если архитектура приложения слишком требовательна к вычислительным ресурсам, то никакая «тонка настройка» не даст существенного выигрыша в производительности и масштабируемости. Для этого потребуется внесение изменения или в архитектуру, или стратегию внедрения, или же менять и то, и другое вместе.

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

Автор оригинала - Randy Stafford

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

(В оригинале - It's never too early to think about performance)

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

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

Однако, если вы не обращаете внимание на производительность вплоть до конца проекта, вы теряете огромное количество информации о том, когда и как производительность меняется. Если производительность играет серьезную роль для системы, то ее тестирование должно начинаться как можно раньше. Если вы используете Agile методологию, основанную на двухнедельных итерациях, то по моему мнению тестирование производительности должно начаться не позднее третей итерации.

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

Этот же подход применим и в случае, когда требуется протестировать то или иное архитектурное решение на соответствие требованиям к производительности. Особенно же это критично для систем со строгими требованиями.

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

Автор оригинала - Rebecca Parsons

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!