Владимир Чернышев

Посмотрите на capistrano. По-моему именно то, что вам нужно. Что не на PHP (почему-то мне кажется, что ваша CMS на нём) — не пугайтесь, освоить синтаксис куда проще, чем синтаксис конфигов «нативного» Phing, предназначеного для тех же целей. Ruby придётся устанавливать только на локальной машине. Документация отличная, но на английском. Примеры использования, в том числе и с PHP проектами, есть и на Хабре.

По вопросу организации самого процесса — сложно советовать не зная особенностей движка и могут/должны ли быть на разных сайтах отличия в коде и других «как бы» сайтовонезависимых файлах и схемы БД. Если могут/должны, то посоветовал бы познакомиться с системами контроля версий (я лично предпочитаю Mercurial, но более популярен Git), впрочем познакомиться с ними стоит в любом случае. И организовать структуру репозиториев/веток примерно так: основная ветка/репозиторий — общий код (+дефолтный дизайн), ответвления от неё/клоны — код каждого из сайтов (туда же можно поместить сайтоспецифичные шаблоны, картинки и т. п.). При следующем обновлении общего кода по очереди мержите (объединяете) код веток/клонов с основным (пожалуй для вашего случая лучше клоны) — что-то автоматически объединится, где-то руками конфликты разрешить придётся и заливаете на сервера (по хорошему надо ещё и тестировать предварительно, но похоже не ваш случай).

Бюджет нулевой, но пару-тройку дней потратить придётся на изучение и организацию. Зато потом любая правка (в том исле изменение схемы данных) в основном репозитории будет распространяться на все сервера одной командой капистрано, оставляя в неприкосновенности их локальные нюансы. Поверьте — оно того стоит!

Вообще это mirror.yandex.ru — спросите у Яндекса :) Я пользуюсь mirror.timeweb.ru. Выбран недавно автоматом и всего 6 хопов из которых 4 провайдерских, а 5-й в DataIX, до этого вообще до Финляндии ближе всего было. Раз в пару месяцев проверяю не появилось ли что лучше.

И как её на флешку закинуть :)

Должно проверять магазины (включая интернет) не Общество по защите прав потребителя, а Роспотребнадзор (Федеральная служба по надзору в сфере защиты прав потребителей и благополучия человека). Инициировать проверку можете вы лично, а может Общество по вашей жалобе (или даже без неё). По результатам проверки должны вынести мотивированное решение вплоть до направления материалов проверки в прокуратуру, полицию и т. п. для решения вопроса о возбуждении уголовного дела. Подать заявление можно в региональных управлениях Службы как по вашему месту жительства, так и по месту нахождения магазина. Кроме того, можно отправить жалобу со сайта rospotrebnadzor.ru/virtual/feedback или обычной почтой.

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

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

Большей частью (модульные) фреймворки и пишутся для реализации функций контроллеров, связи вида и модели. Слово «библиотека» тут не совсем уместно. Библиотеку вызывают из своего кода, а контроллер и есть свой код прежде всего. Вы можете в каком-нибудь users.php написать код получения списка юзеров из Doctrine и его рендеринг в Twig и это будет типичный контроллер, но когда придёте к концепции фронт-контроллера и роутинга, чтобы соблюдать DRY хотя бы, то получите типичный велосипедный фреймворк.

Такая утилита нарушит юникс-уэй :) А он состоит именно в «слишком много сущностей» — каждая программа делает одно дело, но делает его хорошо.

Для получения почты по каким-то критериям, увы, ничего не посоветую (не стояла такая задача никогда — ящики для автоматической обработки всегда были выделены, а спам на них был редок ввиду нетривиальности имен, потому оверхида из--за чтения всех писем не практически не было. Как вариант можете попробовать настроить форвард только нужных (отправитель+аттач) писем на «секретный» ящик и уж оттуда получать всё). А вот для обработки полученной тем же fetchmail'ом (сохранению вложений в частности) попробуйте procmail. Тут есть пример схожего конфига, адаптировать его под ваши задачи не сложно будет, я думаю, одну строчку заменить навскидку.

А если решать задачу в лоб (то есть делать именно то, что нужно и ни операцией больше), то, имхо, нужно писать свой pop3-клиент, который будет ретривить только нужное и не сохранять тело письма.

Кстати, не всегда это хорошая практика. Можно считать это преждевременной универсализацией и оопизацией во многих случаях, если вы точно не уверены, что понадобится несколько классов с разными реализациями, но одним интерфейсом (тестирование отдельный случай, во многом зависит от языка и инструментов, где-то мок/стаб легко создать без интерфейсов, где-то, наверное, невозможно). Вот когда понадобится, тогда и создадите, а достоверая оценка оценка вероятности понадобится или нет приходит только с опытом. Но лучше, имхо, для более быстрого его набирания лишний раз выделить интерфейс из уже реализованного класса, чем выделить сразу, а потом и не вспомнить, что зря его выделял и таскать по всему проекту без особой надобности. А когда интерфеейса не хватате, то это чувствуется, особенно в языках с сильной типизациейю.

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

Раньше использовал assert('is_*($param)') для контроля типа параметров функций, но как-то от этой практики отказался, т. к. ни разу не сработали.

PHPUnit:

$this->assertSelectEqual("title", "Привет мир", 1, file_get_contents("google.ru?q=Привет мир"));

В комментариях, имхо, оно допустимо. В постах — только если пост и так изобилует сленгом и жаргонизмами, тогда глаз не режет. А когда пост написан в принципе грамотным, практически литературным языком, то это слово очень сильно в глаза бросается. На днях был посто какой-то интересный, грамотный, но вот слово «функционал» употребляющиеся пичём не раз очень раздражало при чтении.

Плохо гуглили. Я вот тоже habrahabr.ru/blogs/code_review/135234/ прочитал и сразу в гугл — php code analyzer — ссылка в ответе выше — первая :)

По заданию:
У класса ApacheLogAnalyzer слишком много ответственностей и жёстких связей:
— читает данные из лога (пускай через ApacheLogReader, но всё равно);
— анализирует их;
— пишет их в БД (пускай через MysqlLogDataWriter, но всё равно)

При этом нет никакой явной необходимости инстанцировать ApacheLogReader и MysqlLogDataWriter в ApacheLogAnalyzer. Так же не вижу необходимости инстанцировать mysqli в MysqlLogDataWriter, да и вообще лучше PDO, как указали выше.

Можно сделать без сильного рефакторинга что-то вроде

$reader = new ApacheLogReader('access.log'); 
$db = new PDO('mysql:dbname=fl;host=localhost', 'fl', 'fl'); // @todo Обработка ошибок
$writer = new PDOLogDataWriter($db); 
$analyzer = new LogAnalyzer($reader, $writer);
...

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

$reader = new ApacheLogReader('access.log'); 
$log_elems = $reader->getLogElems();
$analyzer = new LogAnalyzer($log_elems);
$data = $analyzer->getAnalyzedData();
$db = new PDO('mysql:dbname=fl;host=localhost', 'fl', 'fl'); // @todo Обработка ошибок
$writer = new PDOLogDataWriter($db); 
$writer->write($data);

вообще избавившись от этих зависимостей в анализаторе и сделав его ещё легче тестируемым, но тоже без глобальных изменений

Можно пойти ещё дальше, реализовать кучу интерфейсов и паттернов, и сделать анализатор вообще не зависящий ни от источника данных и их формата, ни от места их записи и формата, ни, даже, от метода анализа, но это уже будет, наверное, «ООП головного мозга» и преждевременное абстрагирование :)

>В топку. Отвечать за противоправные действия с IP адресса отвечать будет владелец.

Теоретически у нас действует презумпция невиновности для уголовных преступлений и административных правонарушений. В данном случае должен быть доказан не только тот факт, что какие-то противоправные действия происходили с данного роутера/IP, но и что их производил именно его владелец, а не его семья, друзья, знакомые или просто прохожие. Без чистосердечного признания, свидетелей или взятия с поличным теоретически такие преступления недоказуемы. Гражданскую «ответственность» тоже пришить, имхо, сложно — роутеры, точки доступа и компы не являются средствами повышенной опасности (хотя, имхо, стоило бы), а значит их владелец не несёт ответственности за противоправные действия третьих лиц. Соответствующие пункты в договорах с провайдерами, имхо, ничтожны или касаются, максимум, гражданских отношений с провайдером.

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

Считать себя защищенным от претензий вообще никогда нельзя, претензию могут подать в любое время. Другое дело, имеет ли эта претензия судебную перспективу. Минимум, что нужно добавить к «хитрому» TOS — дать правообладателям возможность связаться с вами на сайте (хотя бы мыло типа abuse@example.com в контактах) и действительно оперативно реагировать на их жалобы, то есть пытаться разбирать претензии в досудебном порядке. Например, если в жалобе содержится достаточно информации, чтобы видеть, что авторское право действительно может нарушаться, то следует, имхо, заблокировать спорный файл от публичного доступа, связаться с пользователем его выложившим, попросить у него в разумный срок предоставить доказательства того, что он выложил его на законных основаниях или чтобы он сам связался с жалобщиком, сообщить жалобщику об этих действиях или сообщить, что не усматриваете признаков нарушения закона. Желательно, чтобы были доказательства того, что вы эти шаги сделали, хотя бы в виде сохраненного отправленного письма и логов, что файл заблокирован или удален. Если хостинг не требует регистрации, то, увы, придётся удалять или блокировать по жалобе, хотя возможно он выложен законно. Но я бы не стал блокировать файлы по жалобам, в которых написано что-то вроде «У вас выложен фильм Аватар, требуем удалить» без указания конкретных урлов или id, а также анонимные.

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

Следует также учитывать, что дела по чч. 2 и 3 ст. 146 УК РФ являются делами публичного обвинения (ст. 20 УПК РФ) и подать претензию может любое лицо, а не только правообладатель.

Не совсем прямой ответ на вопрос, скорее обход проблемы

>Не хочу писать это прямо в Foo.class.php, т.к. движок периодически обновляется, и трогать его «родные» файлы — это как-то не айс.

Нормальные VCS вполне обычно справляются с добавлением пары строк в автоматическом режиме. Сам сейчас работаю над форком одного открытого проекта. Проект на SVN, я работаю в Mercurial(hg) — за месяц было где-то 40 обновлений оригинала — ручное вмешательство в процесс объединения правок оригинала и моих понадобился только один раз и то по какому-то пустяку типа я поменял дефолтный цвет на свой, а они потом поменяли дефолтный и hg не сообразил какой оставить.

Если же оригинальный движок вы используете как библиотеку, то есть его вообще не трогаете, а инклудите его файлы в свой, то вместо форка можно сделать субрепозиторий. А после того как добавите комменты, так ещё послать их авторам оригинального движка, может добавят и проблема исчезнет :)

Его ненужностью для каждой разработки?

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

Прежде всего начните использовать VCS (системы контроля версий), например Mercurial. Git тоже пойдёт. :) Чтобы когда сервер упадет судорожно не вспоминать что и где исправляли в последний раз, а просто откатиться почти моментально на последнюю рабочую версию, а потом спокойно разбираться.

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

Откажитесь от использования ftp, да и других методов ручного деплоя, используйте ssh/scp/rsync и скрипты деплоя (самописные или, например, Capistrano). Как вариант, используйте средства VCS — с рабочего каталога коммитите изменения в репозиторий, на сервере мержите их оттуда с веб-каталогом, главное не забыть закрыть доступ из веба к служебным файлам VCS. Можно использовать хуки для второго процесса, но лучше все же контролировать его.

Используйте хотя бы примитивные миграции БД, не изменяете структуру БД «ручками» в phpmyadmin, а запускайте sql скрипты. Потом сможете хотя бы восстановить последовательность действий приведших к краху. И бэкапы БД даже перед незначительными изменениями схемы. То же к настройкам сервера (их тоже лучше хранить в VCS).

Современные IDE почти всё это позволяют делать через GUI, но сначала, имхо, лучше разобраться как оно работает в консоли.

Всё вышеизложенное написано на основании собственного горького опыта.

Практическое применение:

Поле ввода, которое подразумевает числовое значение, например, сумма перевода. Пользователь вводит строку «тыща баксов». Нормальной валидации нет (почему — отдельный вопрос). Перевод уходит только если сумма больше нуля. Строка преобразуется в ноль и перевод не уйдёт. Если бы преобразовалась в 1 (true), то перевод бы ушел с не очевидной для пользователя суммой, минимум багофича. А ещё лучше в -1 (true true :) ) и вообще никакой валидации — перевод бы получился отрицательным — критический баг.

PHP, имхо, разрабатывался так, чтобы снизить число таких критических багов.