Feature, которой не хватает Живому Журналу больше всего, — возможность чтения френдленты по RSS.

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

Сейчас, вроде, проблема производительности решена; да и особого роста числа активных пользователей у ЖЖ нет.

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

Это объяснение вполне вписывается в нынешнюю политику СУПа, выдавливающего из пользователей деньги под угрозой уничтожения их контента. Такого себе не позволял ни Брэд, ни 6apart.

По-моему, СУП зря переживает относительно баннеропоказов: просмотр записи из френдленты в RSS почти гарантированно приведёт к переходу на страницу этой записи в ЖЖ ради комментариев.

Единственный способ читать френдленту по RSS на сегодня заключается в добавлении в читалку синдикацию журнала каждого френда по отдельности.

Многие онлайн читалки умеют автоматизировать этот процесс: по введённому имени пользователя вытягивают с сервера LiveJournal список его друзей и добавляют все их RSS-потоки.

Тем не менее, синхронизировать эти подписки со списком друзей придётся вручную: при добавлении/удалении френда надо будет добавлять/удалять его RSS-трансляцию из читалки.

Более того, такой способ подписки не даёт возможности читать подзамки. Конечно, можно при подписке указать URL фида в виде http://ljusername:ljpassword@friendusername.livejournal.com/data/rss, но не все читалки принимают такой формат; а те немногие, которые принимают, не могут уследить за безопасностью вашего пароля — например, Яндекс.

Существует способ реализации чтения френдленты по RSS, решающий проблему безопасности пароли и сохранности подзамкочных записей.

RSS-поток френдленты раздаётся по адресу, например, http://ljusername.livejournal.com/friends/rss. Публичные записи транслируются as is, с учётом настроек журналов, в которых написаны эти записи (текст полностью, только первый абзац, только заголовок). Подзамки как таковые не транслируются, даже их URL не идёт в трансляцию в явном виде (чтобы не раскрывать конфиденциальность).

Вместо подзамка в трансляцию идёт пустая запись со ссылкой вида http://ljusername.livejournal.com/friends/9e107d9d372bb6826bd81d3542a419d6, при переходе на которую происходит редирект на сам подзамок.

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

Хеши достаточно хранить в базе в течение двух недель; во френдленту записи, опубликованные более двух недель назад, всё равно не попадают.

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

Update: оказывается, в ЖЖ изобрели костыли, позволяющие читать френдленту по RSS. Эти костыли основаны на стиле S1 (как я понимаю, в качестве шаблона используется xml/rss вместо html — я в своих движках часто использую этот трюк: получается, что для отдачи rss надо только сделать новый шаблон и передать ему стандартные данные) и доступны только платным пользователям.

Если вдруг начала тормозить (подвисать) SSH авторизация, то возможная причина — проблемы с DNS.

По умолчанию в sshd включен Reverse Lookup — сервер пытается определить hostname клиента, и в случае проблем с нейм-серверами авторизация может сильно подтормаживать.

Чтобы убедиться, что именно вызывает подвисание в SSH, надо запустить клиента с ключом -v или -vv (для большей детализации дебага).

Если подвисание происходит после “SSH2_MSG_SERVICE_ACCEPT received“, то проблема может быть именно во включённом Reverse Lookup.

Чтобы отключить Reverse Lookup, надо в файле /etc/ssh/sshd_config прописать “UseDNS no” и перезапустить sshd сервис.

Если ваш Firefox вдруг начал ругаться о том, что сайт “has sent an incorrect or unexpected message. Error Code: -12263“, не пугайтесь.

Это сообщение означает, что у сайта какие-то проблемы с SSL сертификатом.

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

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

Юзабилити сосёт.

Задача: средствами PHP отправить письмо через smtp.gmail.com. Не просто с указанием адреса @gmail.com в поле From:, а именно через гугловский сервер.

Зачем это нужно? Во-первых, на многих хостингах существуют всяческие ограничения по использованию почты. Во-вторых, такое письмо должно выглядеть “белее” письма, отправленного локальным smtp: меньше шансов, что оно попадёт в junk folder.

Основная проблема, которая возникает при отправке письма через smtp.gmail.com и не возникает при отправке писем по smtp через другие, более обычные сервера, состоит в необходимости использования TLS соединения на 465 порт.

Отправить письмо из PHP напрямую через SMTP сервер (а не через mail() или sendmail) можно давно с помощью LGPL библиотеки PHPMailer.

Оказывается, начиная со второй версии, разработчики библиотеки добавили поддержку отправки почты по SMTP по безопасному соединению. Вот code snippet, формирующий правильный вызов метода отправки письма при использовании гугловского smtp:

     $mail->Mailer = “smtp”;  
     $mail->SMTPAuth = true;  
     $mail->SMTPSecure = “tls”;
     $mail->Host = “smtp.domain.com”;  
     $mail->Port = “465″;  
     $mail->Username = “email.address@gmail.com”;  
     $mail->Password = “1W0N’T_t3ll-U”;  

Разработчики библиотеки не волшебники: для отправки писем по безопасному SMTP-соединению необходим PHP с поддержкой OpenSSL.