NPM и left-pad: мы разучились программировать?

Зафиксируйте версию и обновляйтесь только по мере надобности. Зависимости вида * или 1.* или ^1.2 — это все дурной тон.

Почему технический долг — это хорошо

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

bash.im/quote/420672

Утечка реальных ФИО пользователей через Кинопоиск.ру

Именно это предложение больше всего и поразило. Все крупные сервисы, как правило, в начале вводят в эксплуатацию beta.example.com и только после пары месяцев сбора статистики, A-B тестов и прочего, выкладывают наконец все на основной домен. А тут наоборот. Странно.

Мир недокументированного React.js. Context

www.youtube.com/watch?v=KYzlpRvWZ6c&t=1351 вот видео
medium.com/@learnreact/container-components-c0e67432e005 вот статья

Мир недокументированного React.js. Context

Подходит. Делаете глупый компонент, зависящий только от props, и умный, в котором делаете PubSub к чему угодно. Не обязательно все-все смешивать в одном компоненте.

Webpack для Single Page App

RequireJS не умеет подключать файлы без явного указания плагина (css!./path/to.css).
RequireJS не умеет без диких плясок с бубном работать с TypeScript/ES6/Coffee/JADE/SASS, ему надо либо прекомпиляци, либо опять же плагины, а в вебпаке это делается за минуту.

Я создал две одинаковых системы для дичайше огромного сайта и пришел к выводу, что Webpack удобнее, т.к. позволяет на клиенте видеть и при разработке и после билда максимально идентичное окружение. Кол-во багов, которое вылезало из-за разницы в работе на живую и после сборки, было немного удручающим…

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

React на ES6+

Статик есть в TypeScript в примерно таком виде, так что думаю и в стандарт рано или поздно проберется.

ECMAScript 6 Promises

UPD. Я понял, о чем речь была.

function timeout(promise, ms) {
    return new Promise(function (resolve, reject) {
        promise.then(resolve).catch(reject); // вот так
        setTimeout(function () {
            reject(new Error('Timeout’));
        }, ms);
    });
}

ECMAScript 6 Promises

Он там совершенно ни к чему, ловить мы внутри функции ничего не планируем.

Lumen — новый PHP-микрофреймворк от разработчика Laravel

*въедливый режим* А сколько раз он достиг лимита в проведенном тестировании ;)

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

А считать, сколько раз у меня болванка непонятная отдалась — это для продакшена бесполезно, тестировать надо на чем-то очень-очень злобном и ресурсоемком…

Lumen — новый PHP-микрофреймворк от разработчика Laravel

Ну справедливости ради надо заметить, что Yii логи пишет не сразу, а по достижению некого лимита, после чего он их дампит в файл.

$flushInterval public property

integer $flushInterval = 1000

How many messages should be logged before they are flushed from memory and sent to targets. Defaults to 1000, meaning the flush() method will be invoked once every 1000 messages logged.

… из документации

Введение в fetch

А главное — оно так уже лет 10 работает и вряд ли когда-то поменяется.

Введение в fetch

Если бы вы хоть немного знали предмет, о котором вы рассуждаете, вы бы знали, что внутри обработчика beforeunload можно выполнить некие действия, чтоб воспрепятствовать уходу пользователя со страницы (например, при наличии несохраненных данных). Действия, выполняемые в рамках обработчика *обязаны* быть синхронными, иначе он отработает и страница благополучно будет выгружена, а все незакрытые соединения принудительно разорваны.

Введение в fetch

*рука-лицо* что признавать то?

Код на продакшене уже год как работает, в самом начале была проблема с подписками, и эту проблему решили (выше написано как), проблема ушла, саппорт это подтверждает. Клиенты довольны, деньги идут, никто не жалуется.

Введение в fetch

Есть такой сервис pubnub.com, так вот у них все реализовано через лонг-поллинг, они даже веб-сокетную эмуляцию через это написали. Их аргумент следующий, якобы «Protocols, like WebSockets, can get tripped up by cell tower switching, double NAT environments, and even some anti-virus software or proxy boarder authorities.» (источник stackoverflow.com/a/26306148). Это просто к слову.

Введение в fetch

если вы не контролируете сервер, то о чем вообще говорить

Вот именно.

Введение в fetch

Ответил ниже, это и правда слишком очевидно… Но когда нет контроля над сервером — это не решение.

Введение в fetch

Безусловно проще. Но их поддержки у сервера нет. И сделать с этим я ничего не могу.

Введение в fetch

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

«делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули» — это общие слова, напрочь лишенные смысла. На какие, по-вашему, объекты распространяется подписка, о которой говорю я?

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

Про Ваш юз-кейс — вы часто открывали 30 окон одного сайта? И нет, ничего не сломается, подписки будут убиваться в неактивных вкладках и создаваться в активных.

У Вас есть опыт создания подобных приложений? Игр, чатов, мессенджеров? Серверных частей для этого? Или Вы просто умозрительно рассказываете?

Введение в fetch

Сервер все может ;) но лимит есть лимит. У вас есть другие варианты, как обходить ограничение в 30 подписок, если не убивать их при закрытии окон? Поделитесь :) мультиплексирование всех событий через одну подписку в одной вкладке и распространение этого в другие вкладки не предлагать, уже проходили. Каждая вкладка должна иметь свой личный канал для нотификаций.