Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
Именно это предложение больше всего и поразило. Все крупные сервисы, как правило, в начале вводят в эксплуатацию beta.example.com и только после пары месяцев сбора статистики, A-B тестов и прочего, выкладывают наконец все на основной домен. А тут наоборот. Странно.
Подходит. Делаете глупый компонент, зависящий только от props, и умный, в котором делаете PubSub к чему угодно. Не обязательно все-все смешивать в одном компоненте.
RequireJS не умеет подключать файлы без явного указания плагина (css!./path/to.css).
RequireJS не умеет без диких плясок с бубном работать с TypeScript/ES6/Coffee/JADE/SASS, ему надо либо прекомпиляци, либо опять же плагины, а в вебпаке это делается за минуту.
Я создал две одинаковых системы для дичайше огромного сайта и пришел к выводу, что Webpack удобнее, т.к. позволяет на клиенте видеть и при разработке и после билда максимально идентичное окружение. Кол-во багов, которое вылезало из-за разницы в работе на живую и после сборки, было немного удручающим…
Я согласен, что эти два инструмента отличаются буквально в мелочах, но на больших проектах с множеством команд, эти мелочи выливаются в часы и дни.
*въедливый режим* А сколько раз он достиг лимита в проведенном тестировании ;)
На самом деле лично у меня никогда не возникало проблем с производительностью 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.
Если бы вы хоть немного знали предмет, о котором вы рассуждаете, вы бы знали, что внутри обработчика 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). Это просто к слову.
medium.com/@learnreact/container-components-c0e67432e005 вот статья
RequireJS не умеет без диких плясок с бубном работать с TypeScript/ES6/Coffee/JADE/SASS, ему надо либо прекомпиляци, либо опять же плагины, а в вебпаке это делается за минуту.
Я создал две одинаковых системы для дичайше огромного сайта и пришел к выводу, что Webpack удобнее, т.к. позволяет на клиенте видеть и при разработке и после билда максимально идентичное окружение. Кол-во багов, которое вылезало из-за разницы в работе на живую и после сборки, было немного удручающим…
Я согласен, что эти два инструмента отличаются буквально в мелочах, но на больших проектах с множеством команд, эти мелочи выливаются в часы и дни.
На самом деле лично у меня никогда не возникало проблем с производительностью Yii благо многое можно подвергнуть оптимизации, если способ «написал как получилось» тормозит. Особенно слой работы с базой. Как правило самое адское торможение именно на неоптимальных запросах и больших выборках.
А считать, сколько раз у меня болванка непонятная отдалась — это для продакшена бесполезно, тестировать надо на чем-то очень-очень злобном и ресурсоемком…
… из документации
Код на продакшене уже год как работает, в самом начале была проблема с подписками, и эту проблему решили (выше написано как), проблема ушла, саппорт это подтверждает. Клиенты довольны, деньги идут, никто не жалуется.
Вот именно.