Автозагрузка разве что. Группировка — неймпсейсы/префиксы. Приватные статические поля — более глубокий рефакторинг, да ещё небезопасный в общем случае.
код на функциях можно легко превратить в ООП-код путем превращения функций в статические методы и объединения в классы.
И толком никакого профита не получить. Если уж менять функции на методы, то на методы объектов, а не классов, а в месте вызова функции инстанцировать объект и вызывать метод. Кроме всего прочего это иногда позволяет разгруппировать несколько параметров на конструктор и сам метод.
Имхо, если решил писать на php. то надо сразу начинать использовать Linux или *BSD/MacOS для этого.Иначе все возможности языка (включая стандартные библиотеки) и наработки сообщества использовать затруднительно, а то и невозможно.
Можно и так сказать, хотя не совсем точно будет. Низкая связанность компонентов вернее будет, а уж реализуется она через DI.
Ещё раз. Простая реализация RBAC идёт из коробки. Если вам не нужна динамическая конфигурация ролей (создавать роли в админке грубо говоря), то просто задаёте их список в конфиге. Там же в конфиге можете ограничить список урлов для каждой роли. А можно в контроллерах зашить более сложную логику. Список ролей стандартными способами в базе хранить можно. Сложнее если нужно роли создавать в рантайме, но тоже решаемо. Собственно вся авторизация реализуется одним методом isGranted(). А противопоставлять ACL и RBAC я бы вообще не стал. Субъектами RBAC могут являться и роли.
Было, проводил денормализацию БД в целях оптимизации без изменения кода моделей. Собственно основное назначение DataMapper — отделить объекты модели от таблиц БД, чтобы их изменения друг на друга не влияли. Да и раздутым в использовании я бы DM не назвал, особенно при сложной логике, когда в ходе выполнения запроса создаются/изменяются/удаляются несколько несвязанных реляционными отношениями объектов модели — вызываем только раз метод «save» (flush). Собственно даже для «бложиков» мне теперь нравится использовать DM. Например, позволяет комменты к посту хранить в виде json/php-serialize поля в таблице постов, а не использовать 1-to-many и JOIN. И это без изменения кода моделей и контроллеров.
Кстати, на мой взгляд Symfony 2 самый продвинутый фреймворк из всех популярных на популярных динамических языках. Но во многих приложениях такая продвинутость может быть излишня, как излишня, по моему мнению, Java для личного блога. Вот как раз к Enterprise Java идеологии и близок Sf2, наверное. Для стартапов в сфере b2c с циклом близким к Agile методикам всё же Yii порекомендую (по отзывам :) ). Для b2b, для автоматизации хорошо известных бизнес-процессов альтернативы Sf2 имхо нет, если оставаться в области популярных динамических языков.
Видимо я задачу неправильно сформулировал — мне нужно заставить исходник скомпилироваться без его изменения для тестирования локально, чтобы он потом скомпилировался у препода для зачёта. Думал может ключики какие у g++ есть или подскажет кто какой-нибудь старый компилятор.
Об этом я написал, что знаю, но нельзя. Целевой компилятор какой-то, что понимает С++ образца 1991 года, для него и должны быть программы, строго по книжке.
Дата выставления счетов и списания средств индивидуальна. Мне счёт выставляют в конце месяца, а первая попытка списания 3-го числа происходит. Видимо дата зависит от даты заказа.
Такого у меня не может быть в принципе. Моя задача развитие существующего живого проекта, все части которого востребованы — как добавление новой функциональности, так и изменение существующей. Все эти тестирования и рефакторинги я делаю чисто для себя, чтобы, во-первых, быть (более) уверенным, что ничего не сломаю и, во-вторых, чтобы не плодить быдлокод дальше, чтоб не материться на себя же, когда окажется, что нужно уже свой код менять :)
По сути capistrano это скрипт для деплоя, который сам подтягивает себе изменения из репа и заливает их на сервер (плюс миграции БД и прочие «мелочи»). Раньше для этих целей пользовался самописным на баше, работающим через rsync и т. п., но надоело переписывать его для каждого проекта, и только задумался о написании универсального, как статья на хабре о капе :) Получил кучу возможностей, о которых думалось, но руки не доходили, тот же автоматический запуск миграций. Причём навскидку не использую и половины возможностей капа, типа поддержания нескольких серверов в синхронном состоянии для распределенных приложений.
Я склонился ко второму варианту по той причине, что очень много времени пришлось бы выяснять имеющуюся функциональность и алгоритмы. То есть тупо не код писать, а документировать существующий. А так часть «причесывания», включая интеграционные тесты на имеющуюся функциональность и юнит на проведенную декомпозицию, можно сделать и без вникания в код и алгоритмы.
