Многие, наверное, в курсе, что бывает такая замечательная вещь, как контрактное программирование. Если вкратце, то оно подразумевает описание интерфейса, с помощью предусловий, постусловий и инвариантов. Подробнее можете прочитать в вики.
В PHP, контрактное программирование поддерживается с помощью указания типов входных параметров функций, и функции assert().
Зачем?
Иногда нужно повторить механизм синглтонов, максимально простым способом, не используя классы. Обычно это какие-то ядренные (в смысле, находящиеся в ядре) функции, которые подключаются еще до загрузчика(__autoloader) и прочей обвязки. Они должны иметь минимум зависимостей, чтобы исключить любую возможность ошибки. У нас, например, похожей функцинал реализован для установки уровня работы приложения(там чуть сложнее, для сохранения обратной совместимости).
Если вкратце, то да. Подробнее тут.
Думали мы пропали? Ан нет.
Что изменилось по сравнению с RC:
- написали генератор кода – пакет CONSTRUCTOR
- свели консольные утилиты к одной ручке – limb.php
- починили все тесты
- поправили документацию
- переписали туториалы
- переехали на GitHub
ЗЫ: Кстати, с праздником!
Ну вот и RC!
С 2007 года мы жили на trunk-версии. Доколе! Хватит!
hg clone https://limb3.googlecode.com/hg/#RC-prepare limb2010.1
Список изменений настолько велик, что проще описать, что мы умеем:
Continue reading →
Ревизия #2
В порыве пятничного отлынивания от работы, совместно с коллегой, родили нечто.
Нечто позволяет одним запросом обновлять неограниченное количество записей. Причем разные столбцы, на разные данные, в зависимости от уникального ключа.
Нечто имеет следующие недостатки:
- требует уникального ключа
- если строки с подходящим ключом нет, то она добавится
- для построения требует знаний о типах полей таблицы
- мускл на него ругается ворнингами
- NULL таким образом вставить невозможно
Видео со скончавшегося secon’а видимо не будет никогда, поэтому выкладываю только презентацию.
![]()
Ситуация довольно банальная: есть статьи и тэги, связанные многие-ко-многим, и необходимо быстро находить статьи с определенным тэгом или несколькими тэгами. Необходимо обойтись без JOIN и одним простым запросом.
В mysql есть тип данных set, который вполне для этого подходит. Но можно и ручками
Посмотрим взлетит оно или нет:
CREATE TABLE `tests`.`article` (
`id` int(10) unsigned NOT NULL auto_increment,
`mask` int(10) unsigned default NULL,
`cset` set('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20') default NULL,
PRIMARY KEY (`id`),
KEY `mask` (`mask`),
KEY `cset` (`cset`)
) ENGINE=InnoDB;
Добавление записей:
INSERT INTO article VALUES(NULL, 3, '1,2');
Выбор по одному тэгу:
select count(*) from article where mask & 1; //помеченные тэгом #1
select count(*) from article where cset & 1;
Выбор по нескольким тэгам – объединение:
select count(*) from article where mask & 3; //помеченные тэгом #1 ИЛИ #2
select count(*) from article where cset & 3;
Выбор по нескольким тэгам – пересечение:
select count(*) from article where mask & 1 AND mask & 2; //помеченные и тэгом #1 И тэгом #2
select count(*) from article where cset & 1 AND cset & 2;
По скорости варианты равноценны, и на табличке с 500К записей (20 разных тэгов, по 1-20 тэгов на статью) все запросы обрабатывались за, примерно, 0.3 секунды, на средненькой домашней машинке.
Главная проблема ACL – ее размер
Из этой проблемы формируются две гадости: во-первых правила долго писать, во-вторых по ним искать сложно. Попробуем пойти нестандартным путем и решить проблему, сделав роли более селективными.
Continue reading →
Для начала определимся с тем, что мы делаем. Обычно наш продукт состоит из:
- сервера или нескольких серверов
- настроек сторонних приложений (http-сервера, СУБД, прочие хранилища данных и утилиты)
- нашей схемы размещения файлов (фото, видео, и прочий хлам контент)
- наших кэшей
- нашей структуры БД
- нашего кода
- бессоных ночей
Начнем с конца, пропустив бессоные ночи.
