Сколько не пробовал разных систем управления, пришёл к тому, что самая эффективная - это мозг.
Основной принцип GTD состоит как раз в том, чтобы избавить мозг от той части работы, для которой он не приспособлен: хранения тысяы мелких задач и постоянных принятия решений по переходу от одной к другой.
Идея разумна прежде всего в том отношении, что вносит элемент добровольности. Одно дело навязать информацию (что мы имеем в случае с рассылкой), совсем другое постепенно убеждать в ее активности.
BTW, однажды высказывалось довольно разумное, в основе своей, предложение: автоматически постить в блог проекта запись о коммите от имени автора этого коммита. Это создает среду для обсуждения конкретного блока изменений. Останавливает то, что это тоже может стать навязыванием информации.
Вот логи, например, в репозитарий класть не надо — вам не потребуется управление версиями логов. Как не надо класть и упакованный (скомпилированный) код вашего проекта или документацию, собранную по исходому коду. Потому что логи и пакеты собираются автоматически и в любой момент можно эту процедуру повторить.
Я неоднократно убеждался, что это неверно. Если артефакт X можно воспроизвести из других уже размещенных в репозитории артефактов, но это требует значительных затрат времени или других ресурсов, то его имеет смысл также положить в репозиторий.
Примеры:
1. Лог нагрузочного тестирования. Да, мы можем его воспроизвести. Но для этого нужно снова получить железо, которые временно выделялось для теста, и еще раз выполнить нужные прогоны. Итого, к примеру, 18 часов. Один (в лучшем случае) убитый рабочий день. Во вполне реальном случае, когда для тестирования арендовались ресурсы в Data Fort'е, это вместе с выбиванием денег на повторное тестирование заняло бы с неделю. И вызвало бы у руководства резонные сомнения в моей вменяемости.
Кроме того, я не вижу ничего странного в том, чтобы, к примеру, сравнить между собой две версии логов от разных прогонов для упомянутых результатов нагрузочного тестирования я это делал.
Понятно, это не означает, что каждый лог уровня debug, записанный программой, нужно класть в репозиторий. :)
2. Бинарники отдельных компонент проекта. Разработчик получает задание исправить дефект в компоненте A. Он просто поднимает из репозитория исходники этого компонента и бинарники для компонент B, C ... Y, Z, которые нужны для сборки и тестирования. Это занимает 1-2 минуты. Вместо того, чтобы вынуть из репозитория все исходники (15 минут) и провести полную сборку (еще 10 минут).
3. Результаты работы коммерческого софта, на который имеется ограниченное количество лицензий.
Каждому изменению в репозитарии соответствовует тикет ... Не стоит вносить в репозитарий сразу несколько изменений и решать тем самым несколько тикетов, это усложнит исследование и анализ проведенных изменений.
С одной стороны истинная правда. С другой стороны я пока не видел проектов, где это удавалось бы выдержать. Причины банальны:
1. Отсутствие необходимой поддержки со стороны среды разработки. Если учесть, что лень одна из главных добродетелей программиста, то заставлять его вручную переписывать номер тикета из ClearQuest'а в окно ввода комментария Subversion'а можно только очень недолгое время. Стоит отвернуться и все на это забивают. Варианты применения мер типа "лишение квартальное премии за повторное нарушения формата комментария" не рассматриваю. Я так через два месяца останусь в проекте наедине с PM'ом.
2. Зачастую несколько тикетов закрываются одной группой связных правок. Случай, когда несколько тикетов отражают проявления одной и той же ошибки в коде очевиден. Рассмотрим и чуть более сложный случай: для закрытия тикетов X, Y и Z я сделал утилитный класс Foobar и поюзал в классах A (для тикета X), B (для тикета Y) и C (для тикета Z). Под каким тикетом мы будем коммитить Foobar и как это потом нам поможет при разборе полетов?
И, кстати, я совершенно не уверен, что есть реальная необходимость в отслеживании таких связей мне обычно хватает макроуровня, на котором к номеру версии привязан список всех тикетов. Разбор на микроуровне я за прошедший год проводил ровно 1 (один) раз. Действительно, мне бы очень помогли комментарии к коммитам с указанием номера тикета. Я бы потратил не 2 часа, а 10 минут. Но подозреваю, что все остальные разработчики для того, чтобы обеспечить меня этими комментариями, затратили бы на 2 порядка больше времени.
Исталляция боевого кода вообще должна уметь обновляться, а также откатываться к предыдущей версии без каких-либо потерь данных.
Согласно лично моему опыту, не "должна", а "как хорошо, если это удается сделать". Простейший пример: зачастую новая версия имеет новую структуру БД, которая просто содержит больше полей. При downgrade мы либо теряем информацию из этих полей, либо городим дополнительные таблицы и триггеры, чтобы хоть как-то временно сохранить эту информацию и поддержать ее целостность. После 3-4 таких итераций ДБ дизайнер и админ сделают сеппуку на пороге кабинете менеджера проекта.
Второй пункт работать будет, поскольку даже команда из 7 человек делает в течение дня несмертельное количество коммитов.
Я имел неосторожность года 4 назад проверить на команде из 5 человек. Через неделю у 3 из них стоял фильтр, автоматически убивающий извещения о коммитах.
Более того, я очень часто встречаю следующую позицию: "письма от роботов читать незачем, в них все равно нет ничего интересного". Если писем от роботов мало (до 20-30 в день) с этим еще удается бороться. Если больше сизифов труд. Общение с tash can.
Очень показательное сравнение. В том плане, что в списке апачевских дефектов есть дефекты функционала, которые в случае Microsoft реализованы не в IIS. Например, проблемы, связанные с работой http-акселератора. У Microsoft, если мне память не изменяет, за это отвечает ISA. И патчи секьюрити к нему выпускались.
Кроме того, в этой заметке применен и другой демагогический прием: игра на том факте, что у Apache и IIS совершенно разный подход к нумерации версий. Сравнивается одна лишь шестая версия со всем семейством Apache 2.x на всех платформах.
Нет, я согласен, что подход MS к безопасности в последние 5 лет стал радикально более серьезным. Но когда дело доходит до пиара, то основным инструментом опять становится демагогия.
Лично я считаю, что качество кода Apache и качество кода IIS, как давно существующих и развивающихся продуктов, определяется не личными качествами какого-либо выдающегося или отстающего программиста, а средними по отрасли характеристиками кода.
Соответственно, в пределах точности, необходимой для данного обсуждения, :) я считаю качество кода в обоих случаях одинаковым.
"Аргументация автора звучит разумно: каждый лишний вызов представляет собой дополнительную точку, в которой может возникнуть ошибка. Неправильная передача параметра, недостаточный контоль за диапазоном значений, переполнение стека и т.п. — все это те потенциальные проблемы, которые должны быть подвергнуты тестированию и анализу. И это те проблемы, которые потенциально могут быть использованы при взломе."
Если я заказчику что-нибудь такое предложу, то мне, в лучшем случае, предложат обосновать свой выбор с опорой на материалы Microsoft. В худшем пошлют сразу. :)
IMHO, дело здесь не в кроссплатформенности. Просто у Apache уже давно есть живующие бок-о-бок с ним конкуренты, которые радикально лучше выполняют специфическую задачу раздачи статики. Так что на месте разработчиков было бы неразумно тратить время на то, чтобы занять и эту нишу. Возни много, а смысла нет.
Как сказал 20-с-чем-то лет назад мой учитель математики, "схемы и чертежи являются априори порочным методом доказательства и существуют лишь для того, чтобы помочь в создании или разъяснении доказательства".
Apache заменяют обычно там, где идет жестокая раздача статики. Т.е. динамику направляем через Apache+PHP, а статику через что-нибудь быстрое и легкое.
В случае Microsoft выбора веб-сервера на замену IIS просто нет. Так что стандартно рекомендуется использовать Microsoft'овский же HTTP-акселератор между IIS и внешней сетью.
Кстати, не помню, чтобы в GTD был термин "корзинка".
Основной принцип GTD состоит как раз в том, чтобы избавить мозг от той части работы, для которой он не приспособлен: хранения тысяы мелких задач и постоянных принятия решений по переходу от одной к другой.
Ваша проблема в том, что вы не поняли схему GTD. Инбоксу не нужны никакие облака тэгов, поскольку над ним допустимы только две операции:
1. Добавить новый элемент
2. Выбрать очередной элемент. Без всяких условий, поисков и т.п. Строго следующий.
BTW, однажды высказывалось довольно разумное, в основе своей, предложение: автоматически постить в блог проекта запись о коммите от имени автора этого коммита. Это создает среду для обсуждения конкретного блока изменений. Останавливает то, что это тоже может стать навязыванием информации.
Если бы вы почитали исходники этой системы, то данный вопрос, возможно и не возник бы.
Вообще, главное, на мой взгляд, достоинство OpenSource состоит в том, что можно взглянуть внутрь исходников и заранее оценить объем катастрофы...
Я неоднократно убеждался, что это неверно. Если артефакт X можно воспроизвести из других уже размещенных в репозитории артефактов, но это требует значительных затрат времени или других ресурсов, то его имеет смысл также положить в репозиторий.
Примеры:
1. Лог нагрузочного тестирования. Да, мы можем его воспроизвести. Но для этого нужно снова получить железо, которые временно выделялось для теста, и еще раз выполнить нужные прогоны. Итого, к примеру, 18 часов. Один (в лучшем случае) убитый рабочий день. Во вполне реальном случае, когда для тестирования арендовались ресурсы в Data Fort'е, это вместе с выбиванием денег на повторное тестирование заняло бы с неделю. И вызвало бы у руководства резонные сомнения в моей вменяемости.
Кроме того, я не вижу ничего странного в том, чтобы, к примеру, сравнить между собой две версии логов от разных прогонов для упомянутых результатов нагрузочного тестирования я это делал.
Понятно, это не означает, что каждый лог уровня debug, записанный программой, нужно класть в репозиторий. :)
2. Бинарники отдельных компонент проекта. Разработчик получает задание исправить дефект в компоненте A. Он просто поднимает из репозитория исходники этого компонента и бинарники для компонент B, C ... Y, Z, которые нужны для сборки и тестирования. Это занимает 1-2 минуты. Вместо того, чтобы вынуть из репозитория все исходники (15 минут) и провести полную сборку (еще 10 минут).
3. Результаты работы коммерческого софта, на который имеется ограниченное количество лицензий.
С одной стороны истинная правда. С другой стороны я пока не видел проектов, где это удавалось бы выдержать. Причины банальны:
1. Отсутствие необходимой поддержки со стороны среды разработки. Если учесть, что лень одна из главных добродетелей программиста, то заставлять его вручную переписывать номер тикета из ClearQuest'а в окно ввода комментария Subversion'а можно только очень недолгое время. Стоит отвернуться и все на это забивают. Варианты применения мер типа "лишение квартальное премии за повторное нарушения формата комментария" не рассматриваю. Я так через два месяца останусь в проекте наедине с PM'ом.
2. Зачастую несколько тикетов закрываются одной группой связных правок. Случай, когда несколько тикетов отражают проявления одной и той же ошибки в коде очевиден. Рассмотрим и чуть более сложный случай: для закрытия тикетов X, Y и Z я сделал утилитный класс Foobar и поюзал в классах A (для тикета X), B (для тикета Y) и C (для тикета Z). Под каким тикетом мы будем коммитить Foobar и как это потом нам поможет при разборе полетов?
И, кстати, я совершенно не уверен, что есть реальная необходимость в отслеживании таких связей мне обычно хватает макроуровня, на котором к номеру версии привязан список всех тикетов. Разбор на микроуровне я за прошедший год проводил ровно 1 (один) раз. Действительно, мне бы очень помогли комментарии к коммитам с указанием номера тикета. Я бы потратил не 2 часа, а 10 минут. Но подозреваю, что все остальные разработчики для того, чтобы обеспечить меня этими комментариями, затратили бы на 2 порядка больше времени.
Согласно лично моему опыту, не "должна", а "как хорошо, если это удается сделать". Простейший пример: зачастую новая версия имеет новую структуру БД, которая просто содержит больше полей. При downgrade мы либо теряем информацию из этих полей, либо городим дополнительные таблицы и триггеры, чтобы хоть как-то временно сохранить эту информацию и поддержать ее целостность. После 3-4 таких итераций ДБ дизайнер и админ сделают сеппуку на пороге кабинете менеджера проекта.
Я имел неосторожность года 4 назад проверить на команде из 5 человек. Через неделю у 3 из них стоял фильтр, автоматически убивающий извещения о коммитах.
Более того, я очень часто встречаю следующую позицию: "письма от роботов читать незачем, в них все равно нет ничего интересного". Если писем от роботов мало (до 20-30 в день) с этим еще удается бороться. Если больше сизифов труд. Общение с tash can.
Кроме того, в этой заметке применен и другой демагогический прием: игра на том факте, что у Apache и IIS совершенно разный подход к нумерации версий. Сравнивается одна лишь шестая версия со всем семейством Apache 2.x на всех платформах.
Нет, я согласен, что подход MS к безопасности в последние 5 лет стал радикально более серьезным. Но когда дело доходит до пиара, то основным инструментом опять становится демагогия.
Соответственно, в пределах точности, необходимой для данного обсуждения, :) я считаю качество кода в обоих случаях одинаковым.
И производительность, разумеется, не зависит напрямую от количества вызовов.
Они, к сожалению, уменьшены ровно настолько, что перестали читаться тексты. :)
В случае Microsoft выбора веб-сервера на замену IIS просто нет. Так что стандартно рекомендуется использовать Microsoft'овский же HTTP-акселератор между IIS и внешней сетью.