Открыли сессию?

Как часто многие php-сты открывая сессию(session_start()), а если и не один раз то вообще ужас, могут однажды увидеть такое:
"cannot send session cache limiter headers already sent"
 А потом еще и искать, что за нафиг случился...

Одно из решений:

if (!session_id()) session_start();

И больше ни когда не придется видеть ту жуткую надпись.

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

random или псевдо-случайные числа.

Речь пойдет о стандартной функции в php.

rand() -  Generate a random integer.

Однажды ночью обнаружилась  принеприятнейшая ситуация. Тестим мы сервак на высоконагруженность, бомбя его большим количеством соединения за короткий промежуток времени. И тут в одном месте видим потерю соединений в 70-80% случаях. Немного прифигев. т.к. к базе обращений очень мало, циклов больших по проекту не ожидалось..., начали искать...
Долго искали в разных местах...
А была, казалось бы, безобидная функция... Из массива случайно выбиралось значение, потом выбиралось следующее случайное, но с проверкой, чтоб они не совпадали... получалась рекурсия...
И, видимо, при частых обращениях у rand() наступал кондратий, возвращая одинаковые значения, от чего наша рекурсия стремилась к бесконечности. Стоило убрать проверку равенства случайных чисел и все заработало без проблем.

И так:

Никогда не сравнивайте случайные значения.

Ищите либо другой способ реализации функционала, либо удостовертесь, чтоб такая проверка не попадала под большие нагрузки.

Кстати, это же касается и функции random() в MySQL и PostgreSQL.
При очень высокой частоте соединений, такой запрос:

select * from table random() limit 2;

может положить сервак.

Есть подозрение, что это касается и других языков программирования.

Про id и таблицы

И сегодня о таблицах...

В cross таблицах, в качестве ключей, должны храниться только(!) идентификаторы (id) таблиц.

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

Казалось бы, это и так понятно, и все так и делают... А нет, не все. Ну а раз не все, значит это надо  записать и показать тем, кто делает не правильно.

Лень матушка.

Давно собирался об этом написать, сегодня только руки дошли.
Сегодняшнее правило:

Ни когда не ленитесь, когда пишите код.

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

Даты в названии.

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

Даты пишутся только цифрами, разделенные тире(дефисом)(или другим символом, если необходимо). Первым пишем год, вторым - месяц, третьим - день.
blablabla_2011-01-06.txt

Небольшая поправка:
В компилируемых файлах даты можно приписывать к расширению, дабы избегать их компиляции.
(blablabla.erl_2011-01-06).

Главный смысл такой, чтоб файлы можно было легко найти простой сортировкой в директории, а так же легко распарсить при необходимости. Поэтому, если есть и время, то его тоже указываем в похожей последовательности - день, час, минута, секунда.

Данные в JavaScript

Со временем выработалось важное правило:

Хранить данные в яваскриптах (javascript).

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

Статистическая модель.

Речь пойдет об архитектуре MVC, а в частности о моделях.

Собственно правило:

Не писать статичных моделей.



Встретил я как-то модель, а там почти все методы были статичными. На первый взгляд, вроде бы ничего страшного и отвечает каким-то скрытым идеологическим принципам.
Все было хорошо, пока не появилась вторая модель, практически, клон первой, потом третья. И тут встал вопрос, а если еще таких штук 10?
И тут хватаются за голову, ептыть, и все переделывают на ООП, применяют наследование, выделяя базовый класс, а класс каждой модели уменьшается на 80%. И теперь не вызываются простые функции из коробочки, а методы объекта модели, содержащего и методы базового класса.


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