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.

В связи с техногенной катастрофой у нашего провайдера пришлось перенастраивать DNS на юниксе.

Локальный список соответствий IP => HostName хранится в файлике /etc/hosts (в Windows: C:\WINDOWS\system32\drivers\etc\hosts).

Список нейм-серверов хранится в файлике /etc/resolv.conf (в Windows для изменения этого списка надо редактировать свойства соединения):

nameserver 202.54.1.110
nameserver 202.54.1.112
nameserver 202.54.1.115

Я не очень понял, с какой регулярностью система перечитывает этот файл; возможны задержки: новые NS-сервера начинают использоваться не сразу.

Ранним воскресным утром я обнаружил, что сервер мёртв. SSH отвалился, сайты не открываются, сервер не пингуется.

Спросонок успел передумать всё самое страшное: хакнули, заддосили, сдох винт.

Каждый из вариантов был по-своему хорош; внутренний параноик™ очень обрадовался.

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

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

Никто не пострадал, даже серверы не сгорели.

Недоступными оказались 9000 серверов, арендуемых 7500 клиентами; в том числе ушёл в оффлайн сайт соседей из Днепропетровска audiko.net.

Наш сервер был недоступен в течение 36 часов; потом сервер включился, но из-за network issues ему было очень плохо.

Сейчас уже работает всё, кроме почты (заказы, комментарии и прочее). Чиним.

Три стилистических ошибки, которые меня бесят сильнее всего:

1. употребление слова волнительно вместо волнующе;
2. использование предлога за в связке с глаголом скучать (это украинизм);
3. называние пишущей машинки машинкой печатной.

Наша доблестная УкрПошта какое-то время назад перестала ставить на письма (по крайней мере на письма из заграницы) штампы с датой.

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

Так вот, перестали ставить штемпели. И приходит тебе письмо на две недели позже положенного срока, а где оно столько провалялось и не узнаешь.

Продуманная система.

Все holywars, посвященные тому, какой язык программирования лучше, — совершенно бессмысленны.

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

Оценивать язык программирования абстрактно (и сравнивать его с другим) бесполезно.

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

Т.е. для сравнения языков их сначала надо спроецировать на какую-то задачу.

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

Потому что WTF — это производная не от языка, а от программиста.

Профессионал решит задачу на том, на чём скажут. Поплюётся, но сделает VBScript для автоматизации в Excelе. Скривится, но допишет нужный функционал к PHP-шному скрипту.

А вот от кривизны рук никакой язык не избавит. Немного выровнит, но не избавит.

Если бы избавлял, то сидели бы все и писали на C.

Я тут совершенно случайно увидел номер Билана.

Не очень понимаю, как можно посылать это на конкурс и в то же время выступать против гей-парадов.

(глядя на результаты) а зачем в этом конкурсе музыкальные номера вообще?

По-моему, если убрать выступления исполнителей и перейти сразу к голосованию за страны по текущим правилам, то результат будет на 95% идентичным нынешнему.