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

Logstalgia требует поддержки OpenGL и видео картоту с 3D акселерацией.
Для хорошей картинки вам надо, чтоб на ваш сервер было не меньше 100 запросов в минуту. Но вы можете симулировать скорость с помощью параметра -s <секунд>, по умолчанию он установлен 1 к 1.

Команды для интерактивной работы:
(q) Показать отладочную (дополнительную) информацию
(c) Показать Logstalgia лого
(n) Переход к следующей записи в логе
(+) Увеличить скорость обработки лога
(-) Уменьшить скорость обработки лога
(ESC) Выход

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Linux, Web.

© Julia Vorozhko for Мастерство программирования, 2008. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Uncategorized.

Недавно в списке MySQL internals@list появился анонс, про выпуск нового storage engine. Компания DDengine создала новый движок revision engine, набор встроенных прокси внутри MySQL, которые следят за изменениями данных в вашей базе.

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

На данный момент revision engine хорошо работает под Linux. Под другие системы пока, что есть проблемы, но это и понятно, так как версия пока еще 0.1.

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

Например:

create table t1 (
 id int not null primary key,
 c char(10)
) engine=revision comment="InnoDB:DOUBLE";
show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
| t1_revision    |
+----------------+
desc t1;
+-------+----------+------+-----+---------+-------+
| Field | Type     | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| id    | int(11)  | NO   | PRI | NULL    |       |
| c     | char(10) | YES  |     | NULL    |       |
+-------+----------+------+-----+---------+-------+

desc t1_revision;
+--------------------+---------------------+------+-----+
| Field              | Type                | Null | Key |
+--------------------+---------------------+------+-----+
| id                 | int(11)             | NO   | PRI | 
| c                  | char(10)            | YES  |     |
| revision_id        | int(10) unsigned    | NO   | PRI |
| revision_timestamp | timestamp           | NO   |     | 
| revision_deleted   | tinyint(3) unsigned | NO   |     |
+--------------------+---------------------+------+-----+

Ключевое слово “InnoDB:DOUBLE” говорит engine, что надо использовать метод двух таблиц для хранения revision info, в данном случае t1_revision создается автоматически.

Операции над таблицами прозрачны.

insert into t1 (id,c) values (1, 'aaa'), (2, 'bbb');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

insert into t1 (id, c) values (3, 'ccc'), (4, 'ddd');
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

select * from t1;
+----+------+
| id | c    |
+----+------+
|  1 | aaa  |
|  2 | bbb  |
|  3 | ccc  |
|  4 | ddd  |
+----+------+
4 rows in set (0.00 sec)

select * from t1_revision;
Empty set (0.00 sec)

Ничего необычного. Давайте попробуем, что нибудь поменять.

update t1 set c ='changed' where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  2 | bbb     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
4 rows in set (0.00 sec)

show variables like '%revision%';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| revision_select_mode | current |
+----------------------+---------+
1 row in set (0.00 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

delete from t1 where id = 2;
Query OK, 1 row affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  3 | ccc  |           1 | 2008-09-30 05:45:49 |                0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

set revision_select_mode = 'deleted';
Query OK, 0 rows affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c    | revision_id | revision_timestamp  | revision_deleted |
+----+------+-------------+---------------------+------------------+
|  2 | bbb  |           1 | 2008-09-30 05:47:14 |                1 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

select * from t1;
+----+---------+
| id | c       |
+----+---------+
|  1 | aaa     |
|  3 | changed |
|  4 | ddd     |
+----+---------+
3 rows in set (0.00 sec)

Переменная сессии revision_select_mode , переключает режим отображения данных в revision engine.

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

Перевод не оригинальный, текст немного видоизменен, без потери смысла статьи передаваемого Автором текста.

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under MySQL.

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

Кратко содержание:

• Цель рефакторинга
• Простые и сложные методы рефакторинга
• Когда начинать рефакторинг?
• Как начать рефакторинг?
• Как не поломать рабочий код?
• Когда рефакторинг не нужен?
• Каталог методов рефакторинга и примеры рефакторинга

А теперь кратко по каждому пункту.

Цель рефакторинга

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

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

Простые и сложные методы рефакторинга

Простые методы рефакторинга — это базовые, фундаментальные методы применяемые в рефакторинге. Например это: выделение метода, перемещение поля класса, выделение класса, переименование метода, класса или поля и т.д.

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

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

Когда начинать рефакторинг?

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

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

Применяйте рефакторинг при разборе кода. Разбор кода это хорошая практика, когда в команде разработчиков, разработчики проверяют код друг друга.

Как начать рефакторинг?

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

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

Как не поломать рабочий код?

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

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

Когда рефакторинг не нужен?

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

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

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

Каталог методов рефакторинга и примеры рефакторинга

Большой каталог методов рефакторинга можно найти на refactoring.com вместо примеров кода, тут применяются примеры на языке UML.

Также, хороший каталог методов рефакторинга можно найти на wikipeadia, каждый метод снабжен примером на C#.

В заключении

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

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | One comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Development, Высококачественный код, Дизайн, Мастерство Программирования, Усовершенствование Кода.

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

Вот 7 хороших советов для проведения рефакторинга:

1. Всегда выполняйте рефакторинг короткими шагами с перерывом на перекомпиляцию и запуском тестов. Чем меньше ваши шаги, тем лучше вы локализуете потенциальные ошибки и тем быстрее вы их устраните. То, что ошибки будут можно не сомневаться. ;-)
2. Проводите рефакторинг снизу вверх, особенно, если у вас длинная и запутанная цепочка наследования классов. Старайтесь всегда сначала производить изменения в потомственных классах, прежде чем приступать к базовым классам.
3. Вы должны знать основные методы рефакторинга, для этого советую вам купить книгу Мартина Фаулера - “Рефакторинг”.
4. У вас всегда должна быть цель с которой вы производите рефакторинг, не делайте его там где он не нужен или только, если это не первоочередная задача. Чем лучше вы понимаете зачем вы это делаете, тем качественнее будет результат.
5. Не увлекайтесь рефакторингом, рефакторинг не добавляет функционала в программу, поэтому и каких либо видимых результатов вы также не получите. Делайте перерывы для того, чтоб сделать, что то, что можно увидеть и оценить. Тогда ваш начальник будет вами доволен. :)
6. Любой вид рефакторинга можно сделать за 5, 20 минут, максимум за один час. Но в основном рефакторинг является комплексной задачей, которая может выполняться в течении недель или месяцев над действующим проектом. Идея в том, что двигаться нужно постепенно и небольшими шагами, и возможно уделяя этому не больше одного часа в день. Это хороший метод рефакторинга, потому как не занимает много времени и убедить начальство в необходимости будет намного проще, ведь 1 час это так мало, не так ли?
7. В долгосрочной перспективе у вас будет красивый и легко сопровождаемый код, код который написан для людей, а не для машин, код которым вы можете гордиться и показывать в пример, код который работает так как вы этого хотите, и все это за невысокую цену рефакторинга!

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | 7 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Development, Tips And Tricks, Высококачественный код, Мастерство Программирования, Усовершенствование Кода.

Я задался следующим вопросом, что изучать и что читать веб-разработчику с 3-4 летним стажем программирования (PHP)?

Хочу спросить Гуру, что думаете об этом списке. Правильно ли продолжать изучать скритовые языки или возможно лучше выучить Java, с C/C++ знаком хорошо.

Более конкретно.

Новый язык:

• Python
• ROR

Дальше, вот что я нашел в Google по книгам:)

Книги по архитектуре и проектированию:

• Архитектура программного обеспечения на практике - Л. Басс, П. Клементс, Р. Кацман
• Объектно-ориентированные методы. Принципы и практика, 3-е издание Иан Грэхем
• Возможно - Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е издание Гради Буч, Роберт А. Максимчук, Майкл У. Энгл, Бобби Дж. Янг, Джим Коналлен, Келли А. Хьюстон
• Применение UML 2.0 и шаблонов проектирования, 3-е издание Крэг Ларман
• UML. Основы Кендалл Скотт, Мартин Фаулер
• Джон Влиссидес: Применение шаблонов проектирования.Дополнительные штрихи
• Еще есть хороший список книг от Стива Макконнелла в Code Complete (которую я уже изучил), но он очень большой и с чего начать это еще вопрос

Книги по методикам проектирования:

• Введение в Rational Unified Process. 2-е издание Филипп Крачтен
• Фредерик Брукс: Мифический человеко-месяц
• Кент Бек: Экстремальное программирование: разработка через тестирование

Взаимодействие внутри команд разработчиков:

• Время-деньги. Создание команды разработчиков программного обеспечения Салливан
• Панкаж Джалота - Управление программным проектом на практике
• David Allen: Getting Things Done

Кроме developers.org.ua, phpclub.ru, php.com.ua и rsdn.ru может есть еще хорошие ресурсы, которые вы просматриваете регулярно для повышения квалификации, ну и для общения ;-) ?

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | 4 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Профессиональный росто.

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

Способы достижения хорошего кодирования

• Назначить двух человек на каждую часть проекта. У вас как минимум будет гарантия, что хотя бы два человека думают, что код работает.
• Рецензируйте каждую строку кода. В рецензировании кода участвует программист и как минимум еще два человека. Рецензирование кода улучшает его качество, так как программист знает, что как минимум 2 человека будут читать его код, а также это является страховкой на тот случай если человек покинет проект.
• Введите процедуру подписания кода. Подписанный код показывает, что программист соотвествует уровню квалификации и только подписанный код считается завершенным.
• Распространяйте для ознакомления хорошие примеры кода. Это предоставит ясный пример, того качества, которого вы хотите добиться. Никакое описание не передаст более точно, то что можно показать в примере кода.
• Подчеркивайте, что код - это общее имущество. Иногда программисты считают, что код который они написали - “их” личная собственность. Хотя это результат их работы, но он является частью свего проекта и должен быть доступен любому участнику проекта.
• Награждайте за хороший код. 1. Награда должна представлять интерес для программиста. 2. Код поощряемый таким образом должен быть исключительно хорошим.
• Один простой стандарт. Если вы управляете программным проектом и в прошлом были программистом, то простым и эффективным способом добиться хорошего результат будет фраза: “Я должен быть в состоянии прочесть и понять любой код написанный в проекте”.

Стив Макконнелл. Совершенный код.

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | One comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Высококачественный код, Мастерство Программирования.

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

• у вас не установлен старый urchin tracker код
• у вас не включен Ad Block или похожая программа блокировки нежелательного содержания
• у вас не установлены adware, spyware программы, которые фильтруют траффик и могут вырезать нежелательное содержимое

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

<script type="text/javascript">
if (typeof(_gat) == 'object')
{
var pageTracker (YOUR TRACKING CODE)
...
}
</script>

Я буду признателен если вы напишите в комментариях какая у вас была проблема и помогло ли мое решение, решить ее?

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | 3 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Tips And Tricks.

Фото от morganglines

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

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

И вот почему:

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

Программисты должны найти креативное решение задачи, иначе они ее не решат.

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

1. Выучите новый язык

Программисты постоянно учат новые языки, иногда просто ради развлечения, а иногда по надобности. Не ограничивайте себя только тем, что вы сейчас знаете. Развивайте себя и повышайте свои знания.

2. Начните с самого начала

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

3. Спрашивайте про все

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

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

4. Делайте это ради развлечения

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

Постоянное сочетание новых идей и решений, никак не может быть нудной работой.

5. Постоянно проверяйте новые идеи

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

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

6. Найдите страсть

Если вы когда-либо разговаривали в течении нескольких минут с программистом о его работе, то вы наверное очень скоро заметили, что программисты имеют страсть к тому, что они делают.

А у вас есть страсть к вашим идеям и проектам?

7. Мастер своего дела

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

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

8. Начните думать абстрактными ассоциациями

1. Что если использовать компьютер как телефон?
2. Что будет, если использовать веб-сайт как Word процессор?
3. Что если люди будут озабочены тем, что делают сейчас другие люди?

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

9. Думайте о границах как о помошнике, а не как о ограничениях

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

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

10. Не начинайте руководить чем либо, пока сами это не попробуете

Ваш учитель был прав: Нет ничего хуже чем глупый вопрос. Если вы будете придерживаться #3 и даже проверите все предположения, то вы все равно не сможете быть уверенными будет это работать или нет, пока сами не попробуете. Как вы узнаете, что это не работает, пока не попробуете? Вы удивитесь! Но, даже если предложенное решение не работает, то это все равно может помочь вам найти правильное решение.

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

11. Всегда, всегда ищите более простое и более элегантное решение

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

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

12. Не бойтесь использовать чужой код

Красота интернета в том, что решение которое вы ищете, скорее всего уже кем то другим сделано. Когда я создаю новый сайт, я почти всегда использую существующий open-source код. Зачем изобретать колесо?

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

13. Не бойтесь сотрудничать

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

14. Двигайтесь малыми шагами к большой цели

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

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | 3 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Development, Tips And Tricks, Мастерство Программирования.

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

Карл Вигерс. Разработка требований к программному обеспечению

Точно также для проекта по рарзаботке ПО следует определить его рамки и ограничения. Вам необходимо указать, что может делать система, а что не может.

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

Объем первоночальной версии ProductSearch

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

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

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

Вот как я определил первоначальный объем версии 1.0 для ProductSearch.

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

Для покупателей будет реализованы следующие функции:

• Поиск продуктов - результатом поиска является список категорий наиболее вероятно содержащих искомый продукт
• Вывод списка предложений от поставщиков и информацию о цену на конкретный продукт

Для поставщиков будут реализованы следующие функции:

• Регистрация поставщиков
• Возможность добавлять или удалять собственные продукты из системы
• Статистика переходов покупателей на сайт поставщиков
• Статистика просмотра товаров покупателями принадлежащих поставщику

Объем последующих версий

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

Ограничения и исключения

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

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

© Yaroslav Vorozhko for Мастерство программирования, 2008. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Product Search.