Неоднократно встречался, что при включенной консоли без видимых причин не срабатывает JS на странице, всё исправляется отключением всех консолей.

Так же, для тех кто использует команду console.log(); для вывода дебага в консоль Firebugа, будьте бдительны, если вы забудете убрать эту команду из кода и на страничку зайдет человек, у которого этот плагин не установлен, это приведет к ошибке а-ля «console is not a function» (или что-то в этом роде) что и повлечет за собой невыполнение остального джаваскрипта на странице.

Кто ещё не в курсе что за зверь этот Firebug, посмотрите сюда и пользуйтесь на здоровье.

В качестве шаблонизатора используется Smarty (http://www.smarty.net/).
Спустя 3 года с выхода в live начал сдыхать. Это проявлялось дикими тормозами, странички которые в первое время продакшн-жизни грузились 1-2 секунды начали грузиться по 30-40 секунд. Что соответственно и породило необходимость изучить этот вопрос.

Началом исследования были установка систем мониторинга на сервер (Cacti и т. д.), потому что грешили на нехватку системных ресурсов. После недельного контроля стало ясно, что все ресурсы в норме даже в часы пик.

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

Посмотрели в сторону работы Flash-части аппликухи, особых огрех не было найдено, те что нашли — исправили. Но это на ситуацию не повлияло.
Не обминули вниманием и ПХП часть на предмет оптимизации запросов к базе и тому подобного, нашли мелочи всякие, оптимизнули — не помогло.

Оказались в тупиковой ситуации, так как уже не знали куда смотреть.
По чистой случайности заглянули в папку, хранящую кеш-файлы Smarty. Она содержала ни много ни мало 29 тысяч файлов.
После недолгого совещания решили их удалить. Результат был налицо, всё вернулось на круги своя, странички грузятся как в былые времена, сравнительно быстро и без лишних вопросов.

В результате написали крон-скрипт, который раз в 2 месяца делает «зачистку» папочки с кешом.

Мораль: если TinyMCE ругается вот так: «r is not a constructor» или вот так: «o is not a constructor», ну или подобным образом, проверь что бы все файлы и папки были на местах в нужном количестве.

UPDATE
tablename
SET
col2 = LOWER(col1);

где
tablename — название таблицы, над которой происходят манипуляции,
col1 — колонка с исходными значениями,
col2 — колонка с преобразованными в нижний регистр значениями из колонки col1,
LOWER — команда преобразующая значение в нижний регистр;

Соответственно, основываясь на этом примере, можно производить всевозможные манипуляциями с данными из одной или нескольких колонок и записывать результат в третью.

select date(«2008-02-31″);

умный MySQL вернет в результате запроса NULL, ну логично, что в феврале месяце в 2008 году не было 31 дня, да и 30 собственно тоже не было, а вот если написать

select date(«2008-02-29″);

то в ответе получим значение отличное от NULL, а именно эту же дату, что и будет доказательством её валидности и существования.

P.S. Не знаю как в ранних версиях с наличием такой фичи, но в 5.0.24 она есть и иногда бывает очень даже полезной

delete from files
where
folder_id not in (select folder_id from folders) and folder_id <> -1

В этом примере так же учтена корневая папка (-1).

Лечится это всё установкой нормальной таймзоны на сервере:
# ntpdate pool.ntp.org

# tzselect

Спасибо им

Каждый человек, если он не растение  конечно-же, способен с определенной периодичностью генерировать интересные идеи, реализация которых, со временем, начинает приносить либо славу человеку, либо деньги, либо ещё какие-нибудь позитивные штуки. Но есть одна проблема…

Как от идеи пройти все этапы и окончить реализацией? Где взять на это время? Именно нехватка времени является главной преградой на пути воплощения идеи в жизнь. У меня достаточно много товарищей, которые при встрече делятся своими идеями по поводу реализации разноплановых проектов, но лишь малая доля этих идей принимается к разработке. Я неоднократно был свидетелем, когда кто-то в узком кругу высказал какую-то мысль, а через некоторое время в Интернете появляется ресурс, который в точности реализовует высказанную немногим раньше мысль, только в исполнении совершенно левых  людей, которым пришла в голову такая же идея и они нашли ресурсы для её реализации и теперь получают за это какие-то бонусы. Знакомо?

За полгода до появления всем известных социальных сетей, реализующих возможность найти своих школьных друзей и тому подобное, мы с командой неоднократно размышляли на тему создания именно такого ресурса, но дальше слов дело не пошло. Вуаля! Спустя некоторое время сразу пачка такого плана ресурсов в Интернете.

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

Изучая сетевые ресурсы, можно найти достаточно сайтов, которые в плане функциональности либо представляют малый интерес пользователю либо вовсе его не представляют, но, тем не менее, они неплохо посещаются и приносят копеечку. Не переведутся в сети пользователи, которые будут использовать даже самый бесполезный ресурс. Если даже ресурс не представляет интереса русскомыслящему пользователю, то хватает в мире пользователей, которые мыслят слегка по другому и он их точно заинтересует

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

Поделитесь своей идеей с самым близким человеком и если он не скажет: «Друг, да это же лажа!», смело беритесь за работу.

Не бойтесь своих идей! Ищите время и делайте!

Послесловие.
Лично у меня порядка десятка идей, которые будут с вероятностью 80% популярными после реализации.
Четыре мои идеи спустя некоторое кол-во времени были реализованы посторонними людьми и приносят доход.
К сожалению график работы, который я избрал для себя, не позволяет мне уделять время воплощению своих мыслей в жизнь.
По окончанию проекта, разрабатываемого мной сейчас в качестве дополнительного заработка, сделаю попытку завязать с чужими проектами и заняться хотя бы одним своим вплотную.

В двух словах о системе.

Система состоит из вебной и десктопной частей, обмен данными между которыми происходит посредством XML_RPC. Система требует наличия уникальных идентификаторов(GUID) для некоторых сущностей. Объем данных передаваемых с клиентской части на серверную достаточно велик, варьируется от кол-ва экземпляров сущностей созданных на клиенткой стороне. База данных содержит более сорока таблиц, в третьей части которых кол-во записей может превышать сто тысяч. База данных — PostgreSQL. Мультиязычность.

Далее список фишек, с которыми были проблемы или неясности.

1) GUID

В процессе разработки стало понятно что без уникальных идентификаторов мы не сможем просинхронизировать данные между клиентской и серверной сторонами. Было решено сущностям, требующим уникальности добавить текстовое поле размером 32 байта и содержимым, которое генерируется выполнением следующей функции:

[cc lang="php" tab_size="2" lines="40"]function getGUID(){
$str = »;
for ($i=0; $i <100; $i++){
$rand = rand(1,255);
$str .= $rand;
}
return md5($str);

}[/cc]

В последних версиях базы данных PostgreSQL можно автоматизировать процесс генерации уникального идентификатора на уровне базы.

2. UTF-8

Так как система нуждается в синхронизации со сторонними программами и должна реализовывать многоязычность, было решено использовать универсальную кодировку UTF-8. В связи с этим появились несколько проблем. Так как UTF-8 универсальная кодировка значит она должна позволять хранить любые наборы символов на любом языке, она это позволяет, но размер каждого из символов может варьироваться от одного байта до четырех, а для «хитрых» языков, типа китайский и того больше. Грубо говоря символ «a» на английской раскладке занимает в базе 1 байт, а сивол «а» на русской раскладке занимает 4 байта. Отсюда делаем вывод, что поле varchar(32) не сможет поместить фразу «УТФ навсегда», кол-во символов в которой всего 12. Следует обратить на это особое внимание. Также нужно не забыть указать кодировку передаваемых данных в XML_RPC. Так как мы использовали XML_RPC от PEAR, при чем старой версии, пришлось лезть в сам файлик Server.php и там хардкодить строку

[cc lang="php" tab_size="2" lines="40"]

/**
* The present response’s encoding
* @var string
* @see XML_RPC_Message::getEncoding()
*/
var $encoding = ‘UTF-8′;

[/cc]

так как на команду setEncoding(‘UTF-8′) он реагировал не адекватно.

3. Безболезненная расширяемость базы

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

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

2) мы делаем дефайн этого самого продавца и присваиваем ему ID например равный 1. И во всех табличках, где должен участвовать продавец, добавляем поле в которое и вписываем эту единичку(недоделанный простой вариант расширяемости);

3) делаем табличку продавцов, в которой есть 1 продавец и его ID используем в качестве ID в пункте номер 2 (правильный вариант, удоборасширяемый).

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

4. INT(ID) и индексы

Ни для кого не секрет, что каждая табличка в базе, должна содержать автоинкрементный ID типа INTEGER. Некоторые разработчики этим полем пренебрегают, а зря. Так же важным моментом являются индексы.

5. Свои имена

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

6. Рефакторинг

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

7. Чистка кода

Один раз за определенный срок (возьмем 2 месяца) необходимо проводить чистку кода. Например ранее вы использовали ту или иную функцию, а сейчас уже не используете, но так как вы не уверены в том, что эта функция используется только в вашей части проекта, вы её просто комментируете и ставите дату, когда вы её закомментировали. Если претензий типа: «У меня всё отвалилось» не поступало, значит при очередном осмотре кода, можете смело грохать эту функцию за ненадобностью. Можно конечно удалить, положившись на Subversion, но я предпочитаю использовать комментарии.

8. Даты создания/редактирования, активность записи

С давних пор выработал привычку, вне зависимости от таблицы в базе и её наполнения, хранить дату создания и редактирования записи. А так же стабильно добавляю булевской поле «активности» записи. Логика первых двух ясна. А поле активности записи используется для псевдоудаления записи. То есть все записи, у которых поле активности 0 не участвуют в выборках.

9. SQL — роботяга

Логика PHP или других скриптовых языков, работающих с базой максимально должна быть переложена «на плечи» базы данных. Благо современные базы очень много позволяют взвалить на себя. Не стесняйтесь почитать руководства по функциям, вьюхам, триггерам и тому подобному добру.

10. Взаимозаменяемая разработка

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

11. Бинарные данные

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

12. Кеширование

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

13. «Левые» библиотеки

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

Вот в принципе и все, вспомню ещё — добавлю. Жду комментариев и дополнений. Спасибо

• на PEAR’е — http://pear.php.net/package/PhpDocumentor/;
• на Сурсфорже — http://phpdocu.sourceforge.net/.

А промануалиться здесь — http://www.phpdoc.org/manual.php .

Вкратце скажу, что он умеет документировать PHP-код, то есть делать HTML с кликабельным описанием методов, классов и тому подобную инфу. Такая информация зачастую требуется по окончанию определенного этапа в проекте.

Для пользователей Zend Studio (http://www.zend.com/en/downloads/) нет никаких сложностей при в использовании документора, так как он встроен в нее и легко запускается » Tools -> PHPDocumentor «. Правда, если вы используете операционную систему Windows, могут возникать некоторые проблемы с копированием необходимых файлов из за разности слешей. Пару раз столкнувшись с этой проблемой и не найдя моментального решения, решил поднять документор у себя на локали.

Исходники берем либо на сайте либо из папки с ZendStudio . DIRECTORY_SEPARATOR . bin . DIRECTORY_SEPARATOR . phpdocumentor. Копируем их к себе в htdocs/phpdocumentor, заходим http://localhost/phpdocumentor/, в закладке  «Files» указываем  файлы либо папку, файлы в которой надо документировать. Затем в «Output» указываем папку в которую будут складываться htmlки и формат вывода из выпадающего списка. В «Options» указываем название пакета и нажимаем кнопку «create» справа внизу. Чуть ниже в отдельном горизонтальном фрейме можно будет проследить за ходом генерации.

Приятного документирования