Уважаемый ТС, если Вы соизволите изложить более подробные требования к форуму, пишите мне в ЛС. В ином случае пользуйтесь поиском - тему закрываю.
Нифига не понял. На PHP Вы пишете понятней, чем на русском :)
Ну, видимо задача в том, чтобы иметь конфиг-класс, глобально доступный.
Вот мой вариант, используемый на практике. Предполагается, что baseModule лежит мертвым грузом, а кассы типа concreteModule составляют большую часть рабочего кода. При этом может существовать конфиг-класс модуля, которому отдается больший приоритет.
class baseModule { function getConfigProp($prop_name) { // Если свойство не найдено, конфиг-класс кидает исключение; // Раньше я неплохо жил с return null; но исключения идеологически правильнее, // т.к. null тоже может быть значением. // Исключения глобального конфига перехватываются не в самом модуле, а сильно выше. try { // Пытаемся найти свойство в конфиге модуля return $this->getModuleConfigProp($prop_name); } catch (unknownConfigPropException $e) { // Если не получилось, ищем в глобальном конфиге $globalConfig = Config::getInstance(); // типо Синглетон return $globalConfig->getProp($prop_name); } } function getModuleConfigProp($prop_name) { $modConfig = $this->getModuleConfig(); // откуда берется конфиг модуля - дело частное, опустим return $modConfig->getProp($prop_name); }}class concreteModule extends baseModule { function foo() { // поскольку в рабочем коде модулей к конфигу приходится обращаться часто, // отдаем всю логику работы с конфигом родительскому классу. $cfg_var = $this->getConfigProp('my_prop'); }}
Если кратко. Для хранения глобального конфига юзаем паттерн Синглетон. Еще можно тупо хранить данные в статических переменных, и юзать статический же Config::getProp($prop_name) - кому как нравится, Синглетон пафоснее :) Если речь идет о регулярных модулях системы, полезно наследовать их от некого базового класса, который хранит логику работы с конфигом. В данном примере это позволило бы добавить поиск значения в собственном конфиге модуля, не трогая тело модулей.
Эксепшны юзать по вкусу.
P.S. Кстати, это не имеет никакого отношения к оптимизации, просто так удобней :)
В камментах к упомянутой здесь статье на хабре был обозначен здравый список уровней оптимизации:
Я бы сюда добавил оптимизацию алгоритмов (т.е. на уровне метода), хотя очень часто по эффективности это те же блохи.
Так вот. Ясно, что FAQ про архитектуру составить невозможно, ибо всякая архитектура уникальна.
Про кэширование можно устроить конструктивную дискуссию, т.к. здесь кол-во подходов более ограниченное, хотя это тоже во многих случаях аспект архитектуры.
Оптимизация SQL-запросов: во-первых выходит за рамки, обозначенные заголовком, во-вторых (в нетривиальных случаях) - это большое шаманство, такого рода знания слабо поддаются структуризации.
Собственно, можно составить FAQ по ловле блох. Но я знаю несколько поводов этого не делать:
1. Он мало чем будет отличаться от той же переводной статьи с хабра.
2. Он спровоцирует холивар "красивый код VS быстрый код" или "время работы железа VS время работы программиста", или того страшнее "ф-ции VS ООП".
3. Как было справедливо замечено где-то кем-то, многие приемы оптимизации, основанные на использовании альтернативных операторов (или встроенных ф-ций), могут в следующей версии языка давать ровно противоположный результат.
4. Блохи - они и есть блохи, незачем их обсуждать :)
На мой взгляд, было бы полезно:
1. Инициировать дискуссию по кэшированию.
2. Набросать материал по инструментам профилирования.
3. Набросать материал по настройке окружения.
P.S. Почистил ветку от флуда.
Я делал сайт по продаже картин за пиво, правда :) Но я понятия не имею, какое отношение имеет тот сайт к вашему проекту.
Насчет ТЗ, это не пространные рассуждения, а дельный совет. Собственно, у вас есть два способа не зарыться в проект до Второго пришествия. Первый - написать ТЗ, которые будет отлито в бронзе, и любая попытка отступить от которого будет караться расстрелом (разработчика, заказчика). Второй - назвать цену за час работы, и придумывать проект на ходу. Второй способ, как правило, дает более качественный продукт, но чтоб он стал возможным, требуется вменяемый платежеспособный заказчик и некоторое кол-во творческого потенциала с обеих сторон.
Тогда я в упор не пойму, с какой стати Вы о цене спрашиваете на форуме? Если это ваша специализация, так скорее наоборот, Вы должны консультации давать :)
Я бы для начала заложил недели две на толковое ТЗ. Навскидку - тут больше чем на 2 месяца работы программиста особо ничего не придумаешь. А сколько потом это согласовывать и отлаживать придется - вопрос сугубо индивидуальный, зависит от уровня исполнителя и характера заказчика.
rypy, не, мне-то как раз волноваться не о чем :)
Просто я бы действовал как минимум осторожнее. Ну вот ситуация со стороны. Я недоволен исполнителем, устраиваю взбучку. Ладно, после этого можно прекратить сотрудничество, сказав, что такой формат общения неприемлем. Но вместо этого разговор записывают, кладут на музыку и публикуют на потеху сеошникам. Ну вообще это хамство, и я бы, на месте оратора из данного трека, как минимум сильно напрягся, попадись мне эта запись. А по законам жанра - она попадется с хорошей вероятностью, такова жизнь.
Ситуация усугубляется тяжелым характером заказчика и, если верить его словам, невыполнением договора. Я не знаю, зачем при таких обстоятельствах так развлекаться. Но если считаете, что урегулируется - что ж, это хорошо, вам виднее :)
Vita, +1, полностью разделяю твой взгляд на ситуацию.
И еще не очень понимаю, зачем это было в паблик выкладывать, ясно ж какие комментарии будут. Интернет - он, конечно, большой... но, зараза, прозрачный. Если ситуация действительно тяжелая, нафига еще и так подставляться? И правда можно по морде схлопотать.
Пожалуй, мне, как модератору раздела, стоит объяснить.
Как квалифицировать то, что здесь предлагается, с точки зрения законодательства - я лично не очень представляю, и дело, как мне кажется, не такое простое. Случай судебного решения, который Вы описали - это очень интересно, и, думаю, все будут благодарны, если Вы подробнее об этом расскажете - в т.ч. как именно суд квалифицировал правонарушение.
С другой стороны, данный раздел посвящен технологическим вопросам, а с точки зрения технологии этот топик весьма полезен. В отличие от других способов воровства контента, от этого сравнительно легко защититься исключительно программными средствами.
1. Как определить? Мониторить логи на предмет странной активности, мониторить выдачу на предмет дублей. Если бы вражий скрипт стоил дешевле, я бы пожалуй даже купил и расковырял его :) Но и без исходников, думаю, вычислить ботов труда не составит.
2. Как защититься? В каждом конкретном случае рецепт свой, но в целом - составить "фоторобот" тягающего скрипта (куки, юзер-агент, реферер, директивы по кешированию и т.д. - мало кто из ботописателей свято блюдет HTTP-протокол, какие-то мелочи в 90% случаев всплывают). Банить айпишники. Еще вариант - вставлять генеренный js-код, отсылающий обратно на сервер host, который он видит, ну и генерить его так, чтоб не получалось вырезать регулярками (это не сложно). Имея набор хостов-зеркал, айпишников проксей и фоторобот скрипта - фактически можно спать спокойно :) Ну а судя по Вашему комментарию, письма хостеру тоже должны помочь.
И еще важный момент, о котором нужно помнить - пользователи таких скриптов (пожалуй, в отличие от разработчиков) в большинстве своем очень слабо разбираются что в HTTP, что в регулярках. Так что самые простые меры должны давать результат - чаще всего врагу будет проще переключится на другую жертву, чем включать мозги :)
Я достаточно ясно объяснил? А что касается продажи... ну, честное слово - ведь и так найдут, где продавать, был бы спрос.
А, теперь я кажись понял, что именно вы продаете. Тогда это делается еще проще.
Как устроены "правила подмены контента"? Покажите пример какой-нибудь.
