Основным способом ввода информации в CMS через веб являются элементы управления типа <textarea>.

Для удобства пользователей и увеличения скорости ввода информации эти контролы часто заменяют на WYSIWYG-редакторы (What You See Is What You Get).

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

Разработчикам же для внедрения WYSIWYG-редактора требуется установить на сервер сам редактор, настроить его и вставить в шаблон пару javascript строк для замены плоской <textarea> на неплоское поле на клиенте.

При этом разработчики часто совершают ошибку: внедрив WYSIWYG в свою CMS, они не дают пользователю возможности не использовать этот WYSIWYG.

Речь не идёт о тех клиентах, которые не поддерживаются WYSIWYGом — в них контрол выглядит старой плоской <textarea>. А вот если у пользователя нормальный клиент, но при этом, например, интернет по GPRSу, то бедный этот пользователь: чтобы добавить контент ему понадобится достаточно много времени и денег (WYSIWYG подгружает достаточно много дополнительных файлов: javascript, css, images).

WYSIWYG надо внедрять так, чтобы у пользователя всегда была возможность не пользоваться им. Переключение между WYSIWYGом и plain <textarea> должно происходить без перегрузки страницы.

При этом plain <textarea> не должна быть действительно plain: к ней необходимо прикрутить quicktags для гиков.

Из всех WYSIWYGов наиболее удобным является TinyMCE.

Рассмотрим некую предметную область, в которой имеются две сущности: category и object. Теперь рассмотрим два типа отношений, которые могут между ними существовать: один-ко-многим и многие-ко-многим.

Отношение один-ко-многим означает, что объект может принадлежать только к одной категории. В реляционной модели данных это отношение представлется добавлением поля category_id в таблицу объектов. При этом можно с лёгкостью:
1) узнать, к какой категории относится объект;
2) получить список объектов, принадлежащих категории.

Отношение многие-ко-многим означает, что объект может находиться в нескольких категориях. В реляционной модели данных это отношение отражается при помощи дополнительной таблицы отношений с полями object_id, category_id. Каждая запись в этой таблице содержит информацию о том “факте”, что объект с ID = object_id находится в категории с ID = category_id.

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

Если же в предметной области нет необходимости получать информацию о том, какие объекты содержатся в категории, то можно не создавать эту дополнительную таблицу. В этом случае всё, что нам надо получать от этого отношения: список категорий, к которым принадлежит объект. Для этого в таблице объектов можно создать дополнительное поле category_ids, содержащее список ID категорий.

Формат этого списка может быть любым: ID с разделителями, bitmask, внутренний формат какого-нибудь языка (например, serialized array для PHP). Критерий к формату этого дополнительного поля один: удобство использования в CMS.

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

В идеале front-end CMS должен учитывать тот факт, что данные из этого дополнительного поля могут содержать ID категорий, уже несуществующих в системе, и обрабатывать их соответстенно.

Существует способ получить быстродействие без отказа от целостности данных: завести дополнительное поле не вместо дополнительной таблицы, а в дополнение к ней. Хранить в этом поле следует тоже самое — список ID категорий, к к которым принадлежит объект. В данном случае платой за быстродействие является приобретённая избыточность данных.

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

Три коротких заметки про PHP.

1. Kevin van Zonneveld разрабатывает библиотеку php.js — стандартные php функции, портированные на JavaScript. Естественно, не все функции портированы, на данный момент их 114. Не рекомендуется к просмотру людям, не знающим, как передать переменную из JavaScript в PHP — окончательное разжижение мозга (до состояния “каша в голове”) гарантированно.

2. Каким, по вашему, будет результат вызова in_array(”68_105″,array(68,16,123))? Оказывается, у функции in_array() есть третий параметр — [bool strict]. С его помощью можно включить поиск в массиве не только по значению, но и по типу.

3. Только начиная с версий 4.4.0 и 5.0.2 PHP функция sort() умеет использовать установки локали (с помощью флага SORT_LOCALE_STRING). Для более ранних версий (хотя пора уже проапгрейдиться) можно использовать костылик usort($array, “strcoll”)

Сделали релиз новой версии мозгоразминочного сайта.

По-прежнему без блекджека и шлюх, но зато с комментариями, регистрациями, извещениями, поддержкой openid. Перепёрли все лучшие идеи русской блогосферы. Да, дизайна там по-прежнему нет, руки до него так и не дошли. До чего дошли руки, так это до движка: реально симпатичная CMSина получается. Она, как любая настоящая CMSина, находится в стадии перманентной разработки. Более того, чем больше features реализовано, тем длиннее оказывается список новых, нереализованных.

При таком стабильном росте новых features нельзя ждать, пока они все будут реализованы. Потому что все вместе они не будут реализованы никогда. Надо выбрать 10-20 наиболее необходимых, передвинуть их наверх списка и подвести черту. Когда всё, что над чертой, будет сделано (при этом неизменно потянется что-то из-под черты), надо релизить. С оставшимися фичами процедуру повторить. Bugfixes, user reports помогут при выборе того, что должно оказаться над чертой.

У нас на эту CMSину далекоидущие планы, поэтому приходится её вылизывать. Например, хочется вместо вордпрессов использовать именно её, но при этом сохранить все существующие урлы (именно сохранить, а не повесить 301-й редирект). В то же время, нам нужна более широкая функциональность, чем предоставляет wordpress. Правда, у вордпресса две сущности: pages и posts, а нас всего одна: objects. Но у нас есть категории и теги, которые между собой перпендикулярны, а не параллельны, как в вордпрессе. Понятие “категории” мы трактуем несколько нестандартно, в результате кроссворды уживаются рядом с блогозаписями, редактируются одной админкой и обрабатываются одним фронт-ендом.

В user generated content я не верю, поэтому юзеры могут только комментировать. CAPTCHA простенькая: яка країна, такі й теракти. В общем, следите за обновлениями.

Некоторые суеверные люди считают 29 февраля неудачным днём. Криворукие программисты предоставляют этим суеверным дополнительные доводы в пользу этой точки зрения.

1. Павел Хритоненко:

Сегодня этот код упал с экзепшном:

cookie.Expires = new DateTime(DateTime.Today.Year+1, DateTime.Today.Month, DateTime.Today.Day);

2. Yan Liberman:

В процессе запуска SQL сервер, если не установлен серверный сертификат, генерирует новый самоподписанный сертификат. SQL сервер выпускает этот сертификат со сроком действия 30 лет (то есть дата окончания действия сертификата - это дата выдачи сертификата плюс 30 лет). Вот в процесс расчета этой даты окончания действия и закралась ошибка:

SQLDATE_GetDate(&IssueDT);
SQLDATE_ConvertToSystemTime(&IssueDT, &ExpirySysDT);
ExpirySysDT.wYear += 30;
SQLDATE_ConvertFromSystemTime(&ExpirySysDT, &ExpiryDT);

3. Андрей Плахов:

29 февраля функция “сдвинуть на 369 лет” возвращает ошибку “не бывает таких дат”. В этот день в компаниях с гетерогенными environment’ами происходят чудеса. Файлы не копируются, билды не билдятся, сервера не серверят.

Ведь если у вас 29 февраля ломаются программы и сайты, которые остальные 365 дней работают нормально, значит таки да, неудачный это день.

Есть задача: внедрить в контору систему контроля версий. В конторе есть FreeBSD сервер и машины разработчиков under WinXP. В конторе разрабатываются два типа проектов: общие и личные.

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

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

Если меня читает кто-нибудь, имеющий релевантный опыт: помогите разобраться с предметной областью, пожалуйста. Как называется то, что мне надо, и какой софт лучше всего ставить. Спасибо.

Разбирался с реализацией OpenID.Consumerа на PHP. В сети куча готовых библиотек разной степени глюкавости, почти все имеют гигантский размер. Толкового, блокосхематичного объяснения реализации я не встретил нигде.

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

Делов то всего на три метода, на самом деле. А некоторые готовые библиотеки требуют PEAR.

Не в первый раз сталкиваюсь, и всё время забываю: не срабатывает curl при https запросе из php4 на win32 (в стандартной установке). HTTP запросы отрабатываются нормально, а HTTPS — нет.

Помогает выключение опции CURLOPT_SSL_VERIFYPEER:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

Update: я не сильно разбираюсь в настройках Curlа, но по-моему эта же проблема может возникать и на не-windows серверах.

В принципе, программирование — такой же data-mining, как и журналистика. Разница заключается в конечном результате: журналист облекает его в слова и тексты, программист — в код и программы.

Программистам немного проще: у них есть формальный способ самостоятельно проконтролировать качество написанного (и те, и другие, кстати, “пишут”) — работает/не работает. Наличие такого формального контроля не мешает программистам лажать ещё круче журналистов: работать-то оно работает, но как оно это делает.

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

Особенно бесит, когда т.н. программисты мало того, что самостоятельно не могут проделать data-mining, так ещё и оказываются не в состоянии собрать воедино pieces of data, которыми в них кинули miners, и сучат ножками, требуя готовый код.

Рубрики «Гики шутят» представляет: The Last Language War; в переводе на варварский: Последняя Война Языков.

Basic: Actually, I have a question for Ruby…

Haskell: Me too…

ML: Hey, Ruby, what’s your answer to…

Ruby: Hey, hey, hey now! Not too many at a [segfault]

via matiouchkine