Не знаю как вам, но мне не редко случается в ходе отладки приложения долго ковыряться в ядре и библиотеках, только для того чтобы выяснить что ошибка была на самой поверхности, скажем в неверно переданном параметре. И тогда думаешь «кабы не поленился добавить валидацию на входе функции, столько бы времени своего сэкономил!». Сделать то это не сложно, да не хочется портить прозрачность бизнес-логики кучей второстепенных условий. По сути это сквозная функциональность и здесь бы пригодился АОП-подход, но официально PHP по прежнему не поддерживает АОП. Что делать? Мне ныне видится следующее решение.

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

Создавая очередной сервис, я исхожу из следующих соображений:
1. Логин не должен быть слишком короткий (у меня сейчас от 3 символов включительно, для более крупных систем, типа GMail, используется от 6).
2. Логин не должен быть слишком длинный, иначе в каком-нибудь интерфейсе он начнёт что-нибудь неправильно распирать. Я использую логины до 20 символов, но интересно выслушать ваши мнения по этому поводу.
3. Логин может использоваться в адресной строке, при интеграции с SMS и проч. Поэтому оставляем только латинские символы, цифры, подчёркивание, дефис и точку.
3а. Если логин может быть использован как имя поддомена, то эти условия сокращаются до символов латинского алфавита, цифр и дефиса (дефис не может быть первым и последним, он не может повторяться).
4. Иногда очень удобно использовать двойную навигацию: по логину и ID. Например, у нас на одном сервисе используется адрес domain.com/users/<login> для пользователей с логином и domain.com/users/<id> для тех, у кого нет логина (т. н. виртуальные профили, которые зарегистрированы администрацией или другими пользователями). Это приводит к тому, что логин не может состоять только из цифр, чтобы не путать его с идентификатором.
5. Слова-исключения: www, mail, ns1, ns2, ns3, ns4, admin, god, moderator, editor. Первые 6 являются исключениями для совместимости с поддоменами. А какие слова-исключения используете вы?

И основной вопрос к читателям: какие ограничения стоят у вас, и что я забыл?

Disclaimer

Всё нижеописанное относится к Ubuntu 8.10 (interpid), хотя скорее всего затронет и будущие стабильные версии.

Обратите внимимание, что некоторые описанные ниже шаги могут привести к непредсказуемым :) последствиям.

Предистория

Некоторое время назад o4kapuk описывал в статье И снова о раскладке Бирмана как «Добиться поддержки „типографической” функциональности средствами, максимально приближенными к штатным.»

У меня, как дома, так и на работе это решение приводило к следующим проблемам:

1. После перезагрузки раскладка не переключалась. Эту проблему каждый раз приходилось решать вызывая апплет конфигурации и изменение какого-нибудь параметра в «Дополнительных параметрах».
2. После некоторых обновлений раскладка ломалась совсем. Приходилось переустанавливать нужные файлы
3. После обновления на 8.10 метод перестал работать окончательно.

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).