Yuri Morozov

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

Можно печатать и подшивать в папочку "оффлайн данные скрипта".

Вот моя примерная схема, которая была выработана после пары неудачных попаданий «в рабство»
1. Действительно, в договоре стоит указывать порядок сдачи-приема готовой работы: сколько дней принимаются замечания, в какой форме они принимаются (очень полезно требовать все претензии оформлять в виде письма на email).
2. В этом же договоре вся работа бьется на этапы, каждый из которых заканчивается согласованием. После согласования все дополнения по завершенному этапу вносятся с заключением дополнительного договора.
3. Всем клиентам в конце работы выдается мануал с описанием стандартных операций (как добавить администратора, как добавить товар, как добавить страницу и т.п.).
4. В момент сдачи работы стоит заказчику сказать что-то типа «Посмотрите, пожалуйста, до конца недели, все ли вам понятно, и все ли работает правильно. После этого срока я буду заниматься другими проектами и не смогу оперативно внести правки, если они потребуются»

Вот что я подумал, когда прочитал:

> Разработанная собственная «CMS в зародыше с незафиксированным API» — имеется

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

> Опыт работы с высоконагруженными приложениями
> 80 страниц с секунду

WAT?

> Умение хранить в памяти весь проект вместе с его мельчайшими ньюансами

не работал с большими проектами

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

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

C горящими глазами

Есть специальные ножи для открывания блистер-упаковок.
Продаются… в блистере :)

Судя по темпам и направлению развития, у Yii отличное будущее. Тут ведь важно, где будет критическая масса разработчиков, накапливающая базу знаний, примеров, модулей. Я свой выбор остановил на нём, присоединяйтесь. :)

А вот что я повидал:

CakePHP — документирован хорошо, но слишком много в нем всего «магического», рекомендовать бы не стал.

Codeigniter — документирован хорошо, код местами не ахти и не только из-за поддержки PHP4.

Kohana — код красив, документации для разработки вполне достаточно, но с него я шел, случайно увидев Yii.

Zend Framework — с кодом и документацией все нормально, вот только и того и другого слишком много, а доки еще и сумбурны и самые неясные моменты, как на зло, опущены. Я использую ZF как набор качественных библиотек, а не как CMF. Местами неповоротлив из-за слишком мелкодробленой структуры, и как следствия огромного количества классов.

Yii — документация — обильна, прозрачна и вообще прекрасна. Код и архитектура — великолепны. Имеется шикарный ORM. Порог вхождения невысок — прочитайте от корки до корки гайд (не такой уж он и большой) и в бой. За счет грамотного autoload'а — шустр. Рекомендую!

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

ZF слишком уж тяжеловесный, на мой взгляд. А CodeIgniter уже просто устарел.

Необходимо все-таки подстраиваться под реалии жизни, находить программиста с меньшими запросами в другом регионе и работать удаленно