Изменения в Facebook API с 30 апреля 2015 года

Operation Developer Love. Подавление разработчиков в любовном порыве

30 апреля 2015 года вступят в силу, пожалуй, самые драматичные изменения в Facebook API за всю его историю. Они коснутся всех без исключения разработчиков. В сущности, это не столько изменения, сколько ограничения, которые для многих приложений будут означать либо прекращение их существования, либо существенное урезание функционала (которое, опять же, поставит под вопрос смысл их существования).

Нам тоже придется отказаться от фейсбучного функционала на крупном проекте. Я посмотрел сегодня — у нас порядка 30 тысяч пользователей воспользовались этим функционалом за все время, и теперь его не будет. Фейсбук хочет, чтобы все просто сидели в Фейсбуке. В интернете OpenGraph уже называют ClosedGraph, что достаточно точно отражает суть происходящего.

Итак, что же произойдет 30 апреля?
Читать далее 

Перенос WordPress на другой домен: настройки тем

При переносе WordPress на другой домен следует руководствоваться инструкцией Moving WordPress. Есть один момент, связанный с архитектурой движка — из-за того, что некоторые данные хранятся в базе в сериализованном виде (а там присутствует адрес сайта), могут слететь настройки тем.

В инструкции об этом говорится и предлагаются несколько вариантов. Я воспользовался скриптом Search-Replace-DB. Импортировав базу на новом сервере, ничего не трогаем и кладем каталог со скриптом туда, где лежит wp-config.php. Затем выполняем тестовый прогон (предполагается, что сервер БД на localhost'е):

./srdb.cli.php -h localhost -n YOUR_DATABASE_NAME -u YOUR_USER_NAME -p YOUR_PASSWORD -s YOUR_OLD_DOMAIN -r YOUR_NEW_DOMAIN -z

Если все нормально, скрипт отчитывается примерно так:

94 changes would have been made
0 updates were actually made

Далее запускаем реальный прогон без параметра -z:

./srdb.cli.php -h localhost -n YOUR_DATABASE_NAME -u YOUR_USER_NAME -p YOUR_PASSWORD -s YOUR_OLD_DOMAIN -r YOUR_NEW_DOMAIN

Есть и другие варианты — например, плагин WP Migrate DB. Возможно, он удобнее, но я его не пробовал.

Kirby CMS

Открыл для себя очень приятную CMS на файловой основе — Kirby. Простая, понятная, вроде ничего особенного, но ее внутренняя внимательность к мелочам цепляет. Это из разряда «прямо сейчас не нужно, но я бы купил» (она недорогая, особенно для персонального использования). Если делал бы какой-нибудь личный сайт, выкладывал портфолио и тому подобное — самое то. Собственно, и пришел на нее по упоминанию на сайте Джессики Хиш, который сделан на Kirby.

Расширение HyperComments для MediaWiki

Поскольку очевидный спрос есть, да и хочется внести какой-то вклад в проект, выложил расширение HyperComments на mediawiki.org. Добавляет блок комментариев внизу каждой статьи, кроме главной страницы. Все необходимые пояснения там есть. Успешно используется на Рулусе.

Вообще, мне HyperComments сейчас представляется наиболее адекватной из всех систем комментирования. Пожалуй, тут надо Disqus выкинуть и тоже поставить HyperComments.

MediaWiki: решение проблем с производительностью

Каждый, кто устанавливал MediaWiki, замечал, как медленно она работает. Буквально при любом действии вы сталкиваетесь с невыносимыми тормозами (конечно, если сервер не космически быстрый).

В поисках решения этой проблемы вы придете, например, сюда - How to make MediaWiki fast. Ну, или вот общая категория: Performance tuning. Там собраны вполне разумные советы. Однако важно понять вот что: большинство из них дает лишь микроскопический прирост скорости и не решает проблему тормозов кардинально.

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

Mediawiki.org предлагает использовать Squid, но мне с ним никак не хотелось связываться — во-первых, опыт эксплуатации оставил не очень приятные воспоминания, а во-вторых, на промышленном сервере уже стоял Nginx, который отдавал статику по классической схеме в связке с httpd.

Скажем так: здесь могут быть трудности, но настроить можно. Мне это удалось (не исключаю, правда, что придется еще понаблюдать и что-то допилить). Nginx — очень мощный прокси, и когда вы видите, насколько мгновенно он отдает контент, это, конечно, производит впечатление. Главное — подумать, как различать залогиненных и незалогиненных пользователей. Можно найти пример конфига, где проверяется, содержится ли в куке «UserID» — для этого задействуется модуль ngx_lua, я же решил обойтись без него. И второй важный момент — как принудительно удалять страницу из кэша после ее редактирования. Здесь несколько сложнее: для выполнения запроса PURGE, который выдает MediaWiki, потребуется сторонний модуль ngx_cache_purge.

Основы: NGINX Content Caching.

When Anna Met Jony

На TechCrunch появляется много проходных материалов, заметок в стиле «Произошло событие X. Что будет дальше? Мы не знаем». Поэтому я не очень-то слежу за этим потоком, но вот эта статья — When Anna Met Jony — достаточно важная, чтобы ее упомянуть. По крайней мере, важная для моих размышлений.

Да, все — мода. И не только о часах, не только об Эппл речь, ведь и студенты, похваляющиеся друг перед другом своими четырехъядрёными телефонами (или восьми-?) — это тоже явление моды. У них тоже есть соответствующие соображения — носят сейчас такое или не носят, есть ли у меня такое же, как у него, и т.п. 

Кстати, статья напоминает о хорошем фильме, захотелось его пересмотреть:)

Падает memcached?

Обновляйте. Похоже, другого рецепта нет.

У меня были проблемы с 1.4.15 на CentOS 5, с которыми пытался разобраться — бессмысленно. В логи ничего не попадало ни при какой степени детализации, memcached держался несколько часов и вырубался.

Однако вот у 1.4.20 аптайм уже почти две недели.

Ну, расскажи мне, какой ты крутой CEO

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

И то, и другое мне видится бессмысленным.

Если они когда-либо найдут инвестора, это произойдет не потому, что инвестор прочитал на сайте, какие они крутые. Между тем самолюбование так и прет: на сайт выкладываются фотки, краткие биографии «визионеров», люди радостно назначают друг друга CEO, CTO, COO и так далее (прямо сидя в кофейне, я так думаю).

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

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

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

Еще один проект, представитель которого хотел купить у меня похожий на их название домен, похоже, совсем заглох. Уже несколько месяцев ни в Фейсбуке, ни в Твиттере ничего не появляется, а на сайте все так же написано, что они в бете. Ищут деньги. Жаль. Наверное, столько усилий ушло на «построение комьюнити», «контакты с медиа», а продукта так и не появилось.

Блокировка сайтов: что произошло и как быть?

Вчера, кроме сайтов Грани.ру, Каспаров.ру и ЕЖ.ру, которые недоступны и сейчас, были временно заблокированы LiveJournal и сайт «Эха Москвы». Это было связано с требованием Генпрокуратуры закрыть блог Навального (оригинал — в ЖЖ, копия — на «Эхе Москвы»).

Важно понимать роль Ростелекома. Возможно, это ваш провайдер:

rostelekom-vologda

Ростелеком, крупнейший акционер которого — Российская Федерация, не умеет ограничивать доступ к сайту по его адресу (или доступ к конкретной странице сайта). Точнее, он собирался научиться, но пока не получилось. Возможно, помешали различные расходы: например, прежнему руководителю Провоторову при увольнении выплатили 280 млн р. Поэтому блокировка происходит по IP-адресу — думаю, не нужно объяснять, что на одном IP могут находиться тысячи сайтов, и блокировка одного из них закроет сразу все оптом.

Поэтому, пока в стране не запрещено шифрование информации, а интернет еще не переведен на китайскую модель или вовсе не запрещен, полезно узнать, какие у вас есть варианты доступа к информации (а заодно вспомнить свои конституционные права). Варианты есть разные, оперативная информация о том, как обходить блокировки, публикуется на Рулусе: Как зайти на заблокированный сайт.

Если вы считаете, что Ростелеком ограничивает вам доступ неправомерно, позвоните им — вот, например, контактная информация вологодского филиала. Номер технической поддержки 8-125 работает круглосуточно.