Обновить
108
Кирилл Коншин@dfuse

Principal Software Developer

40
Подписчики
Отправить сообщение
Если их миллион — раз не жалуются и не заводят баги, то велика вероятность, что все окей. Миллионы мух не могут ошибаться ;)
Да, но бонус в том, что если в этой библиотеке починят и оптимизируют — вы тоже будете в выигрыше, если обновитесь.
Зафиксируйте версию и обновляйтесь только по мере надобности. Зависимости вида * или 1.* или ^1.2 — это все дурной тон.
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
bash.im/quote/420672
Именно это предложение больше всего и поразило. Все крупные сервисы, как правило, в начале вводят в эксплуатацию beta.example.com и только после пары месяцев сбора статистики, A-B тестов и прочего, выкладывают наконец все на основной домен. А тут наоборот. Странно.
Подходит. Делаете глупый компонент, зависящий только от props, и умный, в котором делаете PubSub к чему угодно. Не обязательно все-все смешивать в одном компоненте.
RequireJS не умеет подключать файлы без явного указания плагина (css!./path/to.css).
RequireJS не умеет без диких плясок с бубном работать с TypeScript/ES6/Coffee/JADE/SASS, ему надо либо прекомпиляци, либо опять же плагины, а в вебпаке это делается за минуту.

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

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

function timeout(promise, ms) {
    return new Promise(function (resolve, reject) {
        promise.then(resolve).catch(reject); // вот так
        setTimeout(function () {
            reject(new Error('Timeout’));
        }, ms);
    });
}
Он там совершенно ни к чему, ловить мы внутри функции ничего не планируем.
*въедливый режим* А сколько раз он достиг лимита в проведенном тестировании ;)

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

А считать, сколько раз у меня болванка непонятная отдалась — это для продакшена бесполезно, тестировать надо на чем-то очень-очень злобном и ресурсоемком…
Ну справедливости ради надо заметить, что 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.

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

Код на продакшене уже год как работает, в самом начале была проблема с подписками, и эту проблему решили (выше написано как), проблема ушла, саппорт это подтверждает. Клиенты довольны, деньги идут, никто не жалуется.
Есть такой сервис 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). Это просто к слову.
если вы не контролируете сервер, то о чем вообще говорить

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

Информация

В рейтинге
Не участвует
Откуда
San Francisco, California, США
Дата рождения
Зарегистрирован
Активность