Лет 5 назад я впервые подключал к сайту Facebook SDK, для правильного внедрения like-кнопки и блока с рожицами. По сути было 3 варианта:

• Разместить ссылку с картинкой, которая бы вела на facebook-страницу для share-а или like-а. Самый быстрый вариант, даже, можно сказать, молниеносный, т.к. не нужно ничего грузить. Но такими кнопками пользуются куда реже, чем если они размещены правильно. Т.е. если нужен не факт наличия кнопки, а результат от её использования, то такой вариант отпадает.
• Внедрение через XFBML-разметку. Дело не хитрое. Размести специальный тег куда требуется. Подключи скрипт. Есть варианты. Настройки задаются в виде аттрибутов тегов.
• Примерно тоже самое но сразу через <iframe/>.

Казалось бы дело совсем не хитрое. Но в процессе эксплуатации выяснилось много неприятных подробностей. Дело в том, что like-кнопка после нажатия показывает специальный popup. И этот popup в vk-like и fb-like реализованы по разному. В vk-like панелька показывается нормально вне зависимости от вёрстки, а fb-like панелька сделана ногами и вызывает кучу проблем, если у вас выше по коду установлен какой-нибудь overflow: hidden, или ещё какая-нибудь особенность вёрстки. Помимо прочего, большое значение имеет то, куда вы эту поганую кнопку разместили. Если это нижний правый угол сайта, то попав вылезет не вверх, как стоило бы ожидать, а вниз. И, либо не поместится, либо разопрёт сайт как попало. Настройки "распирайся вверх", разумеется, нет. Честно говоря возможности этих стандартных контролов просто никакие. 

Помимо внешнего вида, проблемы вызывает ещё то, что соц. сети грузят вашу страницу crawler-ом, для добычи мета-тегов, со специфическим набором http-заголовков. И если ваш сайт в такой ситуации падает (ну мало ли какой баг), то без debug-страницы вы долго будете гадать, в чём же блин дело.

После удачной загрузки страница кешируется. В случае VK навсегда (если верить новому API, то уже не совсем), а в случае facebook, кеш страницы всё таки можно сбросить. Есть специальный инструмент, который умеет показывать ошибки выгрузки мета-данных. К тому же можно вызывать его программно (к примеру при замене og:image).

В очередной раз я столкнулся с facebook like кнопкой сегодня, когда узнал, что они не работают в мобильной вёрстке. Дело оказалось не в этом… Думал поправлю за 5 минут, и в итоге убил весь вечер. Слишком много изменений, порой сильно не очевидных. К примеру:

• Теперь like и share кнопки — это 2 разные кнопки,
• Но share-кнопку можно паровозиком прицепить к like-кнопке. Выглядит забавно.
• SDK обновился до 2-ой версии. И она не поддерживает решения из 1-й.
• При этом share кнопка из 2-ой версии работает в 1-ой.
• Но только на desktop-ах. А на мобильниках она просто ставит для <body/> класс со стилями { overflow: hidden; position: relative } и молча, без ошибок, дохнет. Скролл естественно ломается. Счастливого дебага, суки... да? :-)
• Раньше для отображения картинок при like-ах и share-ах достаточно было og:image разметки. А теперь… Она всё та же, но появились ограничения по мин. размеру — 200х200. Портал для которого я это домкратил, для всех своих тысяч постов использует картинки меньшего размера. Спасибо, facebook… гори в аду.
• Facebook поменял своё отношение к некоторым аттрибутам к <html/>. Вплоть до ругани красным из-за какой-нибудь ерунды.
• Усердно ругается, если используются аттрибуты name вместо property в <meta/>-тегах.

Подлатал, поправил, переделал. Теперь вроде всё работает. Полагаю, что спустя пол-года они снова в одностороннем порядке что-нибудь изменят и всё сломается. В который раз подряд. Причём, наверное, вёрстка like-кнопки будет и через пару лет сильно кривиться в зависимости от вёрстки сайта, на котором она размещена. Догадаться разместить её в <body/> похоже слишком сложно. 

Одновременно с этим на половину сломалась подгрузка изображений vkontakte-ом при share-ах. Причина не ясна. Судя по документации, ему должно хватать og:image. Ограничений по нему не указано. Debug-страницы для просмотра ошибок, похоже, до сих пор нет. Поиск результатов не дал. Спасибо, vKontakte.

Многие разработчики не раз за свою практику сталкивались с тем, что стандартная возможность упаковать объект в JSON падает с ошибкой, или, что хуже, уходит в вечный цикл. Причина тому цикличные ссылки. Пример:

const a = {};
const b = { a };
a.b = b;
JSON.stringify(a);

Получаем закономерный Uncaught TypeError: Converting circular structure to JSON. Но, что если вам, к примеру, для нужд debug-а, потребовался полунепробиваемый метод toJSON?

Хорошая новость! Мы можем его написать самостоятельно. Причём, благодаря наличию таких классов, как Map или Set, без особых ухищрений и извращений. Принцип действия алгоритма достаточно прост: всякий раз, когда мы собираемся упаковать очередной объект (а только они передаются по ссылке, и приводят к цикличности), мы должны проверить, а не упаковывали ли мы его ранее. А т.к. Set и Map в качестве ключа в Map и значения в Set понимают всё, что угодно, включая объекты, не приводя их к строковому виду, то и переложить эту работёнку можно и нужно именно на них.

Circular

Т.е. где-то внутри нашего toJSON будет:

if(map.has(obj))
  return `$circular:${map.get(obj)}`;
map.set(obj, path);

Где path это путь к текущему итерируемому элементу. Таким образом, столкнувшись с объектом повторно, мы, вместо этого объекта, упакуем строку вида $circular:a.b.c. Что будет очень удобным подспорьем при разборе сложных багов.

Element-ы

Не будет лишним проверять — является ли объект DOMElement-ом, Document-ом или чем-нибудь подобным, т.к. эти сущности не просты внутри, но при этом, едва ли представляют для вас интерес:

if(
    obj instanceof RegExp ||
    obj instanceof Date ||
    obj instanceof Element ||
    obj instanceof Document
  )
  return obj.toString();

Получим строку вида [object HTMLDivElement]. 

jQuery

В случае, если вы используете jQuery, то стоит все порождённые ею jQuery-массивы превратить в обычные:

if(obj instanceof $) // jQuery-nodes
    return _.map(obj, (v, idx) => { /* toJS */ });

В моём случае типовым результатом будет — ["[object HTMLDivElement]", "[object HTMLDivElement]"]. Но можно и усложнить схему, конвертируя DOM-ноды в их CSS-path (например: #section.cls[attr="value"]).

NaN & Null

Скорее всего, внутри своего toJSON вы будете использовать typeof obj === 'object'. Напоминаю о засаде — typeof null === 'object'; Не забудьте это учесть.

Про NaN — JSON.stringify(NaN) === "null". Не самый лучший вариант, не правда ли?

if(_.isNaN(obj))
    return '$NaN$';

Дело в том, что JSON не умеет никаких NaN. Но для нужд дебага такие моменты могут быть критичными. Тоже самое и для undefined. 

Текстовый (и не только) файл можно слепить на ходу, используя client-side JS, и отдать юзеру на загрузку. Обычно для этого используют что-то вроде:

var $a = $('<a/>',
	{
		'href': 'data:' + mime + ';charset=utf-8,' + encodeURIComponent(data),
		'download': _.isString(fname) ? fname : 'file.txt'
	})
	.appendTo(document.body);
$a[0].click();
$a.remove();

Т.е. формируется dataURI с указанием кодировки. А её содержимое экранируется за счёт encodeURI.  В случае, если файл превышает некий предел, то начинаются проблемы в Chrome, который не позволяет скачать содержимое ругаясь на ошибку сети. Полагаю, что сбоит или encodeURIComponent, или же длина аттрибута href превышает некую норму. Firefox такими проблемами не страдает — 100+ MiB грузит, в то время как Chrome спотыкается уже на 15 MiB.

Можно попробовать паковать содержимое как base64, оставив суть подхода (dataURI + a[href]) неизменной, а можно воспользоваться Blob-ом.

Blob

Упаковываем строку в Blob-объект:

new Blob([str], { encoding: 'UTF-8', type: mime });

Получаем псевдо-ссылку на этот Blob-ресурс:

const link = (window.URL || window.webkitURL).createObjectURL(blob);

Ссылка будет начинаться с blob://. Подставляем её в [href] и дело в шляпе.

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

PM2 — это обёртка вокруг node-cluster для запуска nodeJS приложения, в виде нескольких instance's, каждый из которых представлен отдельным процессом. При этом, в стандартном применении, в качестве master-а выступает внутренний скрипт пакета pm2, а в качестве worker-ов ваше приложение. Они всё так же могут слушать один и тот же порт. PM2 (а может и не он) сам будет распределять запросы между worker-ами.

Рано или поздно может возникнуть необходимость коммуникации между worker-ами. Как её осуществить? Изначально worker-ы друг о друге ничего не знают, но если подключить require('pm2'), то через полученное API можно добиться многого. Нормальной документации к этому API, похоже не существует. Но большая часть доступных методов общая с CLI API.

Для начала необходимо подключиться к pm2 из worker-а:

const pm2 = require('pm2');
pm.conect(err =>
  {
    // с этого момента можно использовать API
  });

Для получения всех запущенных pm2-процессов (кроме master-а) можно воспользоваться pm2.list(). Он вернёт вам ВСЕ запущенные им процессы, включая те, что никак не связаны с вашим приложением. Включая текущий instance тоже. Возвращённая пачка данных изобилует подробностями. 3-10 KiB всякой ерунды на каждый worker.

Отфильтровать оттуда текущий instance можно сравнив pmID текущего процесса (process.env.pm_id), с pmID каждого worker-а из списка. Для того чтобы выфильтровать лишние процессы, не связанные с вашим приложением, можно воспользоваться name-ом (process.env.pm_id). Это значение name из json-pm2-профиля вашего приложения.

Метод list несколько избыточен, мягко говоря. Можно получить только pmID-ки worker-ов по указанному name-у. Для этого есть pm2.getProcessIdByName(name). Останется только выфильтровать из него pmID текущего процесса.

А для того, чтобы разослать каждому из worker-ов сообщение с данными, есть метод pm2.sendDataToProcessId(id, packet). Где packet должен быть объектом с ключами: topic (строка с ключом сообщения) и data (сами данные).

Получать сообщения можно как штатными методами pm2, через launchBus (что у меня сделать не получилось), так и штатным process.on('message', cb) от nodejs.

В итоге простой broadcast можно организовать примерно так:

// при инициализации приложения
pm.connect(err => {});

// отправка сообщения
function broadcast(topic, data)
{
	pm.getProcessIdByName(process.env.name, (err, ids) =>
	{
		if(err) {}
		else ids
			.filter(i => i != process.env.pm_id)
			.forEach(id =>
			{
				pm2.sendDataToProcessId(id, { topic, data }, err => {});
			});
	});
}

// приём
process.on('message', msg => { /* msg */ });

Ложка дёгтя

На getProcessIdByName на моей машине уходит от 6ms до 15ms. Т.е. очень очень много. Код внутри по любому поводу формирует и гоняет между процессами груду данных. Используются теже механизмы, что и задействуются для pm2 monit. Даже если запрашивался только ID. 

Почему нет никаких стандартных и удобных механизмом для коммуникации между процессами мне не ясно. Причём ни в pm2, ни в nodeJS. С nodeJS впринципе всё ясно, ведь использование node-cluster предполагает, что master всему голова и сам всё порешает. Но в случае pm2 ситуация несколько иная.

Прицепил к этому блогу мобильную вёрстку. Учитывая насколько примитивен здесь дизайн, это оказалось несложно. Заняло 10-15 минут. Хочу остановиться на ключевых моментах.

<meta/>

Для начала необходимо указать браузерам то, что они вольны в определённых пределах менять пикселное разрешение viewport-а. По-умолчанию мобильные браузеры исходят из того, что едва ли сайт адаптирован к мобильной вёрстке, а значит, рендерить его в комфортных для просмотра 500px по ширине = убить всю вёрстку вхлам. Поэтому для viewport-а устанавливается что-нибудь вроде 1280px, и экран мобильника имитирует из себя полноценный монитор.

Если влепить в HTML такой мета-тег: <meta name="viewport" content="width=device-width; initial-scale=1.0"/>, то браузер будет волен взять такой width, который вшит в устройство как комфортный для данной модели. В зависимости от того, какого размера экран, это число будет различным. К примеру если у вас какая-нибудь лопата или планшет, то там и за 1000px может перевалить.

Параметр initial-scale немаловажен, т.к. он фиксирует изначальный zoom страницы в значение 100%. Дескать не надо извращений, всё адаптировано и отобразится хорошо.

Media-Queries

Дальнейшие шаманства, в основном, связаны с media-queries. Для тех кто с ними не знаком, это такая возможность задать ряд CSS правил, которые будут применяться в зависимости от ситуации. К примеру только тогда, когда ширина экрана не превышает x-пикселей:

@media screen and (max-width: 980px){}

Или наоборот, когда не менее х-пикселей:

@media screen and (min-width: 980px){}

Вариаций и трюков довольно много. Но эти два самые распространённые. 

В шапке сайта сверху справа отображается иконка дельтаплана. На малых экранах она перегораживает меню. Скрываем её:

@media screen and (max-width: 980px)
{
    header .sh_top:after { display: none; }
}

YouTube и прочие <iframe/>-ы

С ними всё сложнее. Они отображаются с фиксированными, вшитыми размерами. Но ведь у нас плавающая ширина сайта. Что делать? Главная проблема ― как задать height пропорциональным width? Ну можно сделать, скажем так:

1. Располагаем <iframe/> внутри другого блока-обёртки
2. Блоку обёртке задаём
   • width: 100%
   • position: relative
   • height: 0px
   • padding-bottom: 56.25%
   • font-size: 0; line-height: 0;
3. Самому <iframe/>-у:
   • position: absolute
   • top: 0; left: 0; width: 100%; height: 100%;

Т.е., по сути, мы заставляем <iframe/> занимать 100% родительского блока. А сам родительский блок занимает всю ширину экрана. При этом его высота зависит от его ширины, благодаря свойству padding-bottom. Шрифты гасим в ноль, дабы убрать нежелательные отступы.

Изображения

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

.site_content img {
   max-width: 100%;
   height: auto !important;
}

Т.е. ограничиваем их максимальную ширину (это свойство сильнее, чем width). А height насильно срезаем, задав ему auto. Это довольно грубое и нехорошее решение. Но, увы, других простых решений на этот счёт я не знаю. Проблемы:

• Страница снова прыгает при загрузке, т.к. браузер не знает какой размер примет изображение до того момента, пока оно не загрузится.
• Если рисунок был отображён непропорционально, то теперь он будет отображаться пропорционально принудительно.

Однако результат того стоит. Если вы знаете решение получше, милости прошу в комментарии или мне на почту ;)