Перехват отправляемого email

Начинаем рубрику «для самых маленьких», с решением простеньких проблем.

Есть такая функция в PHP — mail(), и отправляет она, как все знают, электронную почту. Чуть меньше народу знает, что на самом деле отправляет не она, а mail-сервер, которому она просто передаёт письмо.

Ситуация с настоящим mail-сервером при тестировании сайта на локалке (под Windows) несколько неудобна по двум причинам. Во-первых, достаточно геморойно его установить. Во-вторых, при тестировании обычно не нужно действительно рассылать письма по настоящим адресам. Лучше всего в локальной версии все отправляемые письма складывать в отдельную папочку. Сразу видно сколько писем было отправлено, кому и что у них внутри.

Остальной текст под катом

Z-z-z-z

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

Так вот под виндой диски именуются латинскими буквами. И программе, которая его создаёт, нужно эту букву выдумать. И так, чтобы не совпало с уже существующим. Большинство выбирают, казалось бы единственно верный вариант — назвать его просто «Z:». А ведь и точно, вряд ли у машины столько физических дисков. А если и дошло до такого, то другие диски уже давно заняты.

Физических дисков то нет, а вот программ, которые создают виртуальные, в достатке. И каждая думает, что она одна такая единственная и неповторимая. А потом: ой, пардон, такая бяка, диск уже занят, освободите. И ведь изменить букву у многих из них нельзя. Ганьбец!

Кто кого сильнее? print или echo?

Продолжается вселенское мракобесие по «оптимизации» PHP кода. Это там где светлые умы замеряют быстродействие count() и sizeof().
Вот и на Хабре очередной перевод а под ним туева хуча комментариев. Автор, правда, по его словам, сделал не просто перевод, а так же сам рассмотрел смысл такой оптимизации. Имхо, получилось ещё хуже.

Исходное: по возможности используйте require() вместо require_once(). Добавление от переводчика: весьма неоправданная экономия. С require вместо require_once гораздо больше вероятности подгрузить уже подгруженный файл.

Остальной текст под катом

Пароли администратора

Большинство различных форумов заставляют вводить свой пароль при большинстве изменений в профиле. Особенно страдают администраторы, им пароль приходится вводить при входе в админку и на каждый чих внутри неё. Сделано это, несомненно, в целях повышения безопасности. Так как безопасность очень важна, данную фишку даже отключить нельзя.

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

Что делают люди для того чтобы избежать этого геморроя? Ставят себе везде одинаковый простой пароль. 123, например. Более продвинутые админы, залезают в код форума и кустарным методом удаляют это поведение, при это часто что-то нарушая. Ведут ли оба эти способа к изначальной цели — повышению безопасности? Да нихуя подобного. К чёрту ввод пароля на каждый чих!

Ё-ошибки

Тёмочка продолжает жечь. На этот раз в мудаки записаны программисты.

А вот имхо, программиста сообщения об ошибках вообще не должны ебать. Ебать они должны дизайнеров интерфейсов. Пусть они задают вопрос «Почему?» и объясняют ответ на него программисту.

P.S. И очень не нравится неприязнь Лебедева к букве Ё. Слово ебаный без точек читается как с ударением на аебаный, а это несколько коробит.

Это заговор

На одном из форумов человек интересовался, что это за ключевое слово такое в PHP — from. Дескать, Zend Studio его подсвечивает.

Хотел сказать, что, мол, это зенд у тебя палёный и начать тыкать в List of Reserved Words. И тут на тебе — мои NetBeans и Eclipse его тоже подсветили. Предположение, что редакторы путают PHP с SQL не прошло: и SELECT, и WHERE остаются в коде такими же мертвенно чёрными, как обычные константы и функции.

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

Через Жо

Пару недель назад на Хабре перевели статью одного из разработчиков Internet Explorer о том, почему innerHTML не работает с таблицами. Объяснение, почему оно не работает чётко показывает подход использованный в разработки IE. Подход «пиздец, ну и похуй».

Как это было и в прошлый раз с утечками памяти при работе с DOM, и на этот раз, вместо того, чтобы исправлять свой продукт, творцы из MS пишут статьи о том, каким путём проблему можно обойти. Путь, как и обычно, пролегает через жопу и кишечник.

Радуют объяснения из серии: «я мог проверить, что innerHTML у TBODY устанавливался во что-то, начинающееся с <tr>… Звучит достаточно просто, пока вы не начнёте учитывать все варианты. Вроде подающейся строки, например как <!— новые строки —><tr>…». То есть вместо того, чтобы забить на этот гипотетический вариант с комментарием, IE достигает универсальности одинаковой работы для всех вариантов. Универсальности из серии не работает ваще нигде.

1 марта

Прошедшая зима начиналась с полного пиздеца, закончилась, кажется, более-менее вменяемо. Посмотрим, что будет дальше…

PHPLinq

На хабре написали про реализацию Linq на PHP для выборок из массивов.

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

json_encode сосёт

В новой версии PHP, как уже было сказано, пофиксено множество неприятных вещей. Среди них и баг за номером 42 090, опубликованный аж в июле 2007. Баг этот позволял грохнуть процесс посылкой непотребного JSON-запроса. Хотя, видимо, работало это только под Ubuntu (мне не на windows ни на freebsd воиспроизвести не удалось), всё же исправление данной ошибки, несомненно, радует.

А вот json_encode() продолжает огорчать. В документации к нему написано This function only works with UTF-8 encoded data. И правда, от любых других кодировок он просто отплёвывается. Но мне это до без разницы, неприятно то, что и с UTF-8, работает он через жопу.

Вызов json_encode("русский текст") выдаёт гомосятину вида \u0440\u0443\u0441\u0441\u043a… Какого хера? Зачем работая only with UTF, выдавая строку для JS, которая так же работает всегда only UTF, кодировать всё этими идиотскими мнемониками?

Мало того, что вывод превращается в кашу, в которой не разобраться визуально при отладке, так ещё вместо 2-х байт на символ, шлём 6. Вот вам и экономия трафика за счёт ajax’а.

Так что нужно или мириться с этим или извращаться самим на PHP, как это делают люди в комментариях к документации.

Если для каких-то высоких целей универсальности и сохранения совместимости это и необходимо, почему не ввести второй аргумент функции, типа, $mneNahuyNeNujnaSovmestimost? Впрочем второй аргумент там есть: [, int $options=0], как написано, это Bitmask consisting of PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP, PHP_JSON_HEX_APOS. Что означают все эти мракобесные константы не уточняется. Впрочем и уточнение тут не поможет — на любой вызов со вторым аргументом функция ругается json_encode() expects exactly 1 parameter, 2 given и Use of undefined constant PHP_JSON_HEX_QUOT.

Вобщем, ждём, когда adw0rd напишет новое расширение. :)

По страницам: 123456789101112131415