png

По поводу wiki.
Заводите в репозитории папку docs и кидаете туда текстовые файлы с описанием. github умеет красиво показывать определенное форматирование.

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

плюс по сравнению с wiki
1. одновременное редактирование несколькими пользователями
2. крутая история изменений
3. крутой редакторы, разные форматы офисным данных
4. экспорт данных в разные форматы

короче, такой вариант мне очень нравится ) сам пользуюсь )

Коллеги, присоединяюсь ко всему, что сказано выше.
От себя добавлю.
unit-тесты на старый код — это бесполезное занятие, т.к. там наверняка быдло код, его качественными тестами покрыть будет крайне трудоемко. я бы сделал так.
1. на весь новые функционал писать unit-тесты. программистам дать для просвещения макконела и что-нибудь по практикам TDD, SOLID, GOF.

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

3. в качестве CI-сервера я использовал hudson. Меня вполне всё устроило.
тот же Jenkins — это его форк

4. за продакшен должен отвечать только один человек.
можно организовать это так. делаем отдельную ветку, или бранч, или вообще отдельный реп.
это как организуетесь.
в него может комитить только один человек. Этот человек делает ревью всего кода перед тем как залить его в продакшен репозиторий.
соответственно этот человек «выпивает мозги» программистам, чтобы всё так было. Ну а случись что, есть за это дело ответственный, с которого спрашивается в первую очередь.

5. на счет www-скрипта — это уж слишком, если б программистов было человек 30 и функционал выкатывался бы каждый день(или хотя бы раз в неделю разными людьми), то да, а так я думаю оно лишнее.
бывают ситуации, когда приходится делать отладку на боевом комитами и www-скриптом. Кто-нибудь из программистов обязательно так сделает…

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

Попробуйте готовые библы. например, такую.

Я за вариант 2. если нет варианта 3.
Вариант 1 может иногда не работать из-за попадания на лимиты:

можно попасть на 2 лимита
1. превышение максимальной длины запроса
2. превышение максимального количества параметров в IN. да, там тоже есть ограничения

Ограничения есть не только в мускуле, но и в оракле, постргессе и других БД.

Вариант 2 ещё к тому же и тормознутый, если у нас много записей во внешнем запросе.

Простые запросы будут работать быстрее:
select * from table1,table2 where условия
или запрос через
join
select * from table1 join table2 on условие where условия

какие из них, будет работать быстрее смотрите сами. Настройки БД подпиливаются под данные и под запросы, которые будут исполняться на этих данных.

Коллеги.
Во-первых, согласен с тем, что говорилось выше. Это тоже правильно. Сам делал аналогичные вещи, перекрывал ошибки, писал в лог, слал на почту и т.п.

Во-вторых, если бы меня попросили сделать такую фичу в хорошем добротном проекте, то я бы не стал изобретать велосипед, а воспользовался решением из коробки.
Популярные фреймворки Symfony2, Yii — уже поддерживают это из коробки, причем достаточно давно.
Переполнение по памяти не проверял, остальное ловит без проблем и отдает 500 ошибку, то есть как надо(поправка выше, не обязательно отдавать 503-ю. можно любую 5хх, этот жест скажет поисковику — «Ой, спроси меня позже...», 404 — в таком случае лучше не отдавать, оно может повлиять на позиции сайта в поиске — если для вас это важно.).

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

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

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

Пример с ошибками и статусами HTTP — не единственный. Возможны и другие варианты.

Идея вот в чем. Что и как нужно делать — зависит от вашего проекта. Это может быть не сложный сайт, который отдает информацию, а может быть достаточно сложный комплекс, в котором заложена бизнес-логика, она может отрабатывать как при получении страниц, так и при выполнении фоновых заданий(например, скрипты в CronTab).

Если в двух словах, то я думаю так:
— разбить код логики на блоки (желательно независимые, они могут быть ирерархичными).
— запускать эти блоки как бы «в песочнице» (вопрос как — зависит от самого приложение, у кого-то может и не получиться, или придется ради этого менять структуру БД, какие-то алгоритмы внутри приложения и т.п.)
— по успешному выполнению блока, применяем результат. Что-то сломалось, уведомляем админа о критичной ситуации.

Критичные ситуации лучше всего ловить Unit-тестами, а если это не возможно, то всеми видами тестирования.

Вот, как-то так.