if in_array($id, range(0,100)) echo '...'; elseif in_array($id, range(532, 638)) echo '...'; elseif in_array($id, range(..., ...)) echo '...';
Код-то в принципе подходящий, но зачем там in_array?
if($id>=0 && $id<=100) echo '1'; elseif($id>=532 && $id<=638) echo '2';
и так далее.
"Эстеты" могут написать
echo ( $id>=0 && $id<=100 ? '1': ($id>=532 && $id<=638 ? '2': '3' ) )
P.S.: switch тут конечно можно использовать, но мы бы не стали и уж по крайней мере не так:) В документации написано "and execute a different piece of code depending on which value it equals to". То есть речь именно о вычисляемом значении.
Т.е. хотя штука с условиями в case и работает, тем не менее мы бы не стали увлекаться недокументированными возможностями, хотя бы из-за того что
$a=0; switch($a) { case ($a < 100):echo 1;break; case ($a > 100):echo 2;break; }
выведет цифру 2
Потому что $a==($a>100) есть true в таком варианте. Ибо происходят именно сравнения того, что в $switch с тем что в условиях. Тогда уж правильнее писать так
$a=0; switch(true) { case ($a < 100):echo 1;break; case ($a > 100):echo 2;break; }
по понятным причинам.
Наблюдали такое не раз, в том числе и на своих форумах. Нужен однозначно независимый модератор. Который все переходы на личности будет удалять. Модератор может быть и зависимым в принципе, но должен быть беспристрастным. Персону модератора никто знать не должен лично, кроме администрации, иначе не избежать "ах вот он тех наказал, а этих нет, потому что". В принципе он нужен с самого начала был:)
Как вариант. Модератор может не удалять личную перепалку, а складывать в отдельный раздел форума типа "разборки", куда вход будет только тем, кто непосредственно участвует в какой-нибудь из этих бесед.
В любом случае все общение с админами/модераторами только в личке или в разделе специальном. Из общих тем - сносить и удалять. Ибо иначе все начнут ненавидеть не друг друга, а администраторов.
Дальше по ситуации. Есть 3 основных ситуации.
1) На форуме есть сильно превосходящая группа старичков, которые защищают свои интересы и отпинывают остальных. Являются зачинщиками споров и перехода на личности. Нередко это бывает когда на форуме "уже все обсудили". Типичный симптом - старички постоянно посылающие новичков в поиск, вместо ответа на вопрос.
2) На форуме есть несколько сильных группировок, тоже не молодых. С диаметрально противоположными интересами. Типичный симптом - лавинообразное разрастание любых топиков с припоминанием старого.
3) На форуме завелось несколько троллей, которые алогичными или атипичными рассуждениями раздражают в принципе нормальных людей. Типичный симптом - непонятно в чем дело, но все пересрались.
В 1 и 2 варианте причина скорее всего в том, что люди уже все обсудили и по делу больше говорить не о чем.
В 1-ом варианте нужно поставить на место это группировку. Попробовать мягко. Если не получится, тогда жестко. Главная опасность - уведут за собой кучу народу, но даже в этом случае остальные настолько легче вздохнут, что эффект будет положительный. Один из вариантов - создать раздел, куда вход будет только старичкам.
Во 2-ом варианте опять же надо ставить на место. Можно попытаться создать конкурентную среду. Репутации, спасибо за посты и так далее, т.е. что бы вместо срача друг с другом люди пытались накрутить себе бонусики. А за переходы на личности карать. Можно устроить показательное выступление, главное донести мысль до обоих сторон, что кто первый нажал "пожаловаться на пост", тот и прав, а если ответил прямо в топике, то редиска по любому даже если был спровоцирован.
3-тий вариант самый простой. Найти троллей и уничтожить. Несколько худший вариант это кащениты, но кащениты очень падки на внимание, и если направить их в нужное русло, сделать модераторами например, может получится намного лучше чем если просто забанить.
И небольшое замечание. По нашему опыту от момента старта форума проходит где-то 2-3 года (в зависимости от тематики может быть и 1-5 лет) пока все кто там был уже "обсудят все" и у них появится время "что бы переходить на личности". Нужно не паниковать, а дать уйти тем, кто форум уже перенос и создает нездоровую обстановку.... если не уходят - помочь. Форум скорее всего потеряет много "топовых" старичков при этом, но всплывут новички. При чем те, которые раньше боялись даже региться и писать что-то, именно из-за споров и личностей. Появятся новые точки зрения, новые мысли, появится свежая струя. Которая со временем раскачает форум еще лучше. И возможно даже вернет старичков.
Результатом может стать то, что даже те, кому нравился Ваш форум, могут подумать о создании или уходе на альтернативный ресурс. А за 2 дня головы сильно не остынут. Хватит этого максимум на неделю. Надо разбираться жестче:)
В самую суть проблемы не вникали, но увидели конструкции вида
<tr> <td width="69" height="60"><img src="/tpl/main/images/spacer.gif" width="69" height="2"></td> <td width="100%" align="left"><img src="/tpl/main/images/top_drel.gif" width="206" height="60"></td> <td width="45">.
Средняя ячейка 100%, хотя есть боковые - это странно. Типа в середине 100% и еще немножко:)
Тупо вырезали из кода все <td width="100%", точнее заменили их на <td - помогло
Если нужно просто вылечить симптомы, а не найти причину, то можно просто в начале скрипта поставить
ob_start("abazaba"); function abazaba($a) { return str_replace('<td width="100%"','<td ',$a); }
P.S.: Кстати если уменьшить картинку по ширине до 470, то тоже всё нормализуется, может это поможет.
Хотелось бы обратить внимание на то, что теоретические рассуждения это одно, а практика это другое.
Конечно, в теории, программер берет коробку и строго по АПИ, документируя свои действия, пишет культурный и оптимальный код. Который потом легко кому угодно передается. К сожалению в большинстве случаев, программер который достаточно умен и профессионален, не сильно заинтересован в клепании однотипных сайтов на потоке, ему это будет просто скучно. И вот тут-то и выходит на первое место практика. Неслабое количество сайтов "на коробке" это именно "куча своего кода", убивающая все те теоретические преимущества. Если конечно речь идет о проекте чуть более индивидуальном и крупном, чем очередной каталог.
Второй интересный минус коробок, это заказчики любящие что бы все было с точностью до запятой выверено как им хочется. Такой заказчик потратит 2 недели времени что бы меню было именно таким как он хотел, при этом забьет и отложит внедрение нужной платежной системы. Немного утрируем что бы показать суть. Кстати на западе таких въедливых заказчиков еще больше чем тут, поэтому и коробки там на фрилансе не так популярны. "Своя" цмс позволяет выполнять мелкие прихоти заказчика более быстро и оптимально. И опять же, можно работать и заниматься делом, а не объяснять заказчику почему для реализации его прихоти, такой мелочи, нужно 2 недели, вместо 1 дня.
Минусы "своих" цмс достаточно очевидны, так что даже останавливаться на них не видим особого смысла.
А глобально всё банально. Типовой проект - типовой движок. Много особенностей проекта, требующих солидной доработки типового движка - уже есть смысл задуматься об индивидуальном движке. Потому что когда количество доработок становится таким, что "типичности" в движке остается очень мало, то и смысл в коробке теряется, ибо коробка как раз индивидуальным движком и становится уже... только не сильно приспособленным под нужды, в меру своей изначальной "универсальности".
Ну, еще конечно коробки бесценны для быстрого старта. Когда рекламу уже запустили, а сайта еще нет:)
Еще что хотелось бы добавить. Надо не забывать о таком "среднем" варианте, иногда оптимальном, как фирменный фреймворк, распространенный. Его использование устраняет солидное количество недостатков обоих подходов.
Если у нас не 1 база, а 5, то мы обойдемся вполне 1 набором функций и 1 глобальной переменной. Если Вам для этого же без классов понадобится 5 наборов и 5 отдельных глобальных переменных, то вот это действительно быдлокодерство, и с таким подходом даже классы не помогут улучшить код.
Мысль верная, но этот пример надуманный. Никто не мешает создать функцию, которая будет приводить объект в строковое представление, в зависимости от его типа. Фактически реализуя классы, Вы и создаете по одной функции на каждый тип объекта. Просто они разбросаны по разным классам, вместо того, что бы быть в одной функции.
А разницы в использовании между echo $db->toString и echo toString($db) на самом деле не много, согласны? И в обоих случаях разработчик может даже не знать, с каким классом работает.
То есть классы безусловно предоставляют удобство реализации некоторых вещей и стандартизацию их реализации, но не предоставляют практически ничего абсолютно уникального и нереализуемого через функции.
Именно так, Вы абсолютно верно уловили. Классы в php применительно к веб, это лишь некий стандартный способ реализации некоторых вещей, соглашений, способов раелизации чего-то. Фактически форма записи, что в принципе тоже полезно, а в больших проектах просто необходимо.
С технической точки зрения классы более ресурсоемки и у Вас появляется необходимость таскать за собой переменную-экземпляр постоянно ( $db->query($sql) покатит только если переменная откуда-то протащена, а для query($sql); можно и не таскать за собой этот хлам) или же привязываться насмерть к статическому имени класса (типа db::query()).
ООП без классов в php выглядит ничуть не хуже, а местами даже лучше. Да и работает побыстрее зачастую. За примером далеко ходить не надо - drupal тот же самый, думаем многие хотя бы слышали о нем.
Хотелось бы пояснить. Мы нисколько не против классов, и тем более ООП. Мы очень даже за. Но нужно выбирать использование классов по правильным, а не надуманным причинам. Мода на ООП к сожалению привнесла кучу надуманных аргументов в пользу использования классов в пхп. И если ориентироваться на эти аргументы, то получается жуткий код, в котором нет ничего ООП-шного и красивого и стройного.
По поводу оплаты в хетзнер. С биллингом у них действительно странно, нас за один сервер еще за декабрь не забиллили. Наверное, ждут пока евро совсем взлетит:)
Но по делу. С оплатой визой/маестро именно от альфабанка мы о проблемах с самыми разными сервисами и магазинами слышали не раз. При чем не раз это звучало в контексте "не принимают по соображениям безопасности, ибо много кардеров именно оттуда" (ну а почему нет, банк-то крупный?). Не знаем насколько все это достоверно на самом деле, но именно по этой причине брали карту в другом банке (балтбанк если интересно) в свое время и проблем именно с картой ни разу не испытывали.
Но у альфабанка для расчетов в интернете есть тип карт "виртуал" и с ними вроде как проблем ни у кого не наблюдалось. Возможно это "спасет отца русской демократии":)
neolord, Вы в своём репертуаре, безаппеляционно несете чушь:)
В-первых, в веб-приложениях подразумевается не только "хороший пхп код", но и "хорошая работа с базой". То что Вы написали сортировку "массива" на пхп очень быстро, это конечно круто, но соотношения 95%/5% (база/пхп) Вам удастся достичь только если Вы совсем через одно место сделали выборку данных для сортировки из БД.
Во-вторых, спасибо конечно за ссылку. Но кроме заголовка "get rich with php, increase speed of script into 100 times" Вам неплохо было бы и содержание прочитать, прежде чем рекомендовать ее как "демонстрацию оптимизации php кода для ускорения в 100 раз". Оптимизация кода говорите? Изначально скрипту нужно было 100 серверов. Отключаем ssl в postgre и включаем постоянные коннекты к базе, получаем уже 5 серверов. Переходим на мускул и включаем в нем кэш, получаем 3 сервера. Включаем apc на полную и получаем 2 сервера. (до 1 сервера с 2 действительно немного пхп кодом дошли, но на общем фоне это смешно и не заметно). Вся оптимизация считайте просто настройки сервера, при чем самый большой кусок - это настройка работы с БД.
"Движок" простите отрабатывает 100% времени:) Странно считать "движком" только чистый пхп код. Движок это и пхп код и работа с базой.
Хотя ситуация на самом деле знакомая аж до боли (мы иногда занимаемся оптимизацией чужих скриптов). Классический пример 95/5 соотношения это старушка phpnuke 7-ых версий, которая легчайшей правкой работы с БД превращается в 50/50, а то и 30/70 соотношение.
В пхп коде вообще трудновато накосячить так, что бы время выполнения значительно увеличилось. Так что рассказы о "виртуозном владении пхп так, что он работает в 9 раз быстрее и получается 95/5 вместо 50/50" нас как-то не особо цепляют. А вот работа с БД (обратите внимание, именно работа с БД в целом, а не просто "запросы") как раз очень частый повод для оптимизации, при том результат может впечатлять, даже если работу с БД писал вполне себе нормальный программер не наделавший сильных косяков.
Есть редковато применяемое решение, выгодное с 4 точек зрения
Пихать в каждую форму юзеру uniqueid, валидный только на 1 пост запрос.
В чем бонусы
1) Можно не перезагружать страницу юзеру, не мучая его редиректом.
2) Нет лишнего редиректа, нет лишней загрузки полной страницы, серверу хоть чутка но полегче.
3) Чутка становится лучше по безопасности, т.к. примется только мессага с уникальным ИД, которое сайт сам выдал юзеру (на левых сайтах уже формочки не пройдут).
Это не спасет от одинаковых сообщений как таковых, но спасет от сообщений из одной формы, которые могут быть одинаковы.
4) Слегка помогает от спамеров, по причине пункта 3. Т.к. некоторые спам-боты тупо постят стандартные данные в форму из своей базы, а не сканируют форму каждый раз.
Непосредственно от посылки одинаковых сообщений, спасает банальная проверка на такое же сообщение от юзера в течении предыдущих Х минут (или просто в этом же топике от него же).
По ситуации - можно или склеивать с предыдущим (при условии что запощено в тот же топик) или просто не пропускать.
P.S.: От двойного клика так же есть смысл в любом случае "защищаться" яваскриптом, делая кнопку субмита неактивной сразу после клика на ней. Это конечно не защита, но тоже бывает полезно.
Если навсегда, то да. А так, кто мешает использовать shmop или memcached ? Не у всех хостеров конечно стоит, но тем не менее. А если свой сервер, то имхо вообще грешно без хотя бы одного из подобных плагинов обходиться.
Хе. Сначала Вы говорите что файлы работают медленнее, потом тут же иронично советуете хранить переменную в "параллельном измерении". А по Вашему MySQL где-то в параллельном измерении хранит данные?:) В тех же самых файлах она их и хранит, только интерфейс доступа к ним понавороченнее, за счет этого "при прочих равных" mysql как раз помедленнее, если речь идет о простых операциях.
"При прочих равных" согласны абсолютно.
Но на практике не всегда. Тут надо учесть, что у некоторых хостеров mysql работает на отдельном сервере, а не на том же самом. Или хотя бы на отдельном диске. Тут как бы причину не надо думаем объяснять (грубо говоря, на сервере с вебсервером может быть 1000 грузящих сайтов на одном сата диске, а на сервере с мускулом может быть 10 баз на скази в рейде:) )? Просто этот момент надо учитывать, когда делается кэширование на диск. Потому что иногда его, как ни странно, действительно быстрее делать в базу.
Не в каждый момент времени, а только в тот момент времени, когда идет то или иное обращение к переменной. По поводу "непредсказуемого типа" это что-то странное, это как в анекдоте "кто родился? мальчик? нет! а кто?!?!?!?!?!" (с)
Дальше.
Во-первых - просто еще раз сошлемся на компилируемые функции, которые могут принимать в качестве аргумента переменную разных типов. Типов ограниченное количество и сделать обработчик на каждый тип не так трудно, по сути тип будет просто одним из аргументов вызываемой функции.
Да, это конечно не идеальный выход, но это отнюдь не "непреодолимое препятствие" которым обычно это изображают. И ни в коем случае не превращает компилятор в интерпретатор (несмотря на действия в зависимости от типа), т.к. результат всё равно байт-код, пусть даже немного раздутый.
Во-вторых, если вернуться от "абстрактного" разговора к конкретному. В php вообще нету типов int, double, float и так далее как таковых. Там есть один единственный тип - zval (по сути структура или даже скорее класс если говорить в си терминологии). Так что - нет разных типов - нет проблемы типизации. Это конечно сильно утрированное и упрощенное изложение, но тем не менее в общем и целом верное.
Позволим себе процитировать
http://php.find-info.ru/php/016/ch20lev1sec2.html (да и вообще рекомендуем этот учебничек полистать, нам нравится:) )
To fully understand types in PHP, you need to look under the hood at the data structures used in the engine. In PHP, all variables are zvals, represented by the following C structure: struct _zval_struct { /* Variable information */ zvalue_value value; /* value */ zend_uint refcount; zend_uchar type; /* active type */ zend_uchar is_ref; }; and its complementary data container: typedef union _zvalue_value { long lval; /* long value */ double dval; /* double value */ struct { char *val; int len; } str; /* string value */ HashTable *ht; /* hashtable value */ zend_object_value obj; /* handle to an object */ } zvalue_value;
P.S.: Т.е. мы как бы не хотим сказать, что компилятор для пхп набросать легко и просто и на коленке за 5 минут. Просто в данном случае, мы говорим именно о том, что отсутствие строгой типизации в php не является непреодолимым препятствием
