Нейтрино не разрушает нити дезоксирибонуклеиновой кислоты. Не вижу смысла в применении нейтрино, иначе как для передачи информации на большие расстояния. :)
«Главное, чтобы подстанция выдержала» (ц) А так, да, гамма-излучение способно решать широкий спектр проблем, в частности, я вижу решение проблемы перенаселения.
Интересно.
В общем ваши тезисы мне понятны. Я, для себя, не принимаю следствие, т.к. повсеместно использую кеширование, везде предусматривая callbacks, когда кеш теряет актуальность, но это, как мне кажется — предмет диалога, нежели спора.
Однако начинающие разрабы поставят max-age и будут утверждать, что google chrome кэширует method DELETE. Отсутствие лишнего напряжения может привести к многочасовому дебагу в виду того, что разработчик «скопипастил серебряную пулю и растолкал по папкам».
Вы, возможно, возразите, что «хождение по мукам» неизбежно для разработчика, но я возражу, что, например, неделя для js — вызывает butthurt в 146% случаев, и подводить к такому спорному решению — зло.
Кешированием должен заниматься сервер приложений. max-age — жестокий брутфорс, в моих приложениях он всегда 0.
Я с трудом могу представить себе систему в которой контент не меняется динамически. Homepage?
Я не считаю себя крупным серdиcом, у меня всего 10 картинок на амазоне лежит, однако пути к ним все s3-eu-west-1.amazonaws.com/foo-bar/magnify.jpg?1350015777. А браузер пусть сам запоминает видел ли он эту картинку или нет.
Весь html динамический, кэш отдает сервер приложений, потому, как веб-сервер не может знать, изменились ли данные объекта и, соотвественно, изменилось ли содержимое представления.
Веб серверу нельзя управлять кешированием! Однако, веб сервер должен уметь читать заголовки в которых ему четко и ясно скажут, что свежак, а что 304.
А я вот тут картинки обновил на сервере. У пользователя они будут через месяц?
Js на неделю? у меня 3-4 выкатки на staging в день, большая часть касается js css
Html на день?
Да что такое, почему? Почему вы предлагаете ограничить возможность изменения данных на уровне веб сервера?
Маки сделаны из того же железа что и вин-линукс машины. Да мониторы с Retina, но это все еще мониторы.
Я считаю эти рынки разными. Разработку я веду в убунте, игрульки у меня на винде, а о маке я мечтаю.
Кто угодно, но они сертифицируют свое железо под под Win8. Точно также как Apple сертифицирует свое оборудование. Только сертификация Apple у Apple проходит автоматически и бесплатно, по понятным, я думаю, причинам.
iOS-ы ставится на Apple, Windows8 на Windows 8 Ready, Ubunty на Ubuntu Ready. Я вижу здесь не проблему, а разные рынки.
Apple же решает, что запускается на сертифицированных кстройства, а что нет. И ничего, держатели ай-устройств выгядят вполне презентабильно, левый глаз у них не дергается, шерсть мягкая и блестит на солнце.
Во первых внесенная погрешность не случайна.
Во вторых, «почти случайные» синонимичны «псевдослучайным» сигналам в данном контексте.
Даже если генерировать псевдослучайные сигналы взять за основу «белый шум», некорректно говорить о случайности.
В общем ваши тезисы мне понятны. Я, для себя, не принимаю следствие, т.к. повсеместно использую кеширование, везде предусматривая callbacks, когда кеш теряет актуальность, но это, как мне кажется — предмет диалога, нежели спора.
Однако начинающие разрабы поставят max-age и будут утверждать, что google chrome кэширует method DELETE. Отсутствие лишнего напряжения может привести к многочасовому дебагу в виду того, что разработчик «скопипастил серебряную пулю и растолкал по папкам».
Вы, возможно, возразите, что «хождение по мукам» неизбежно для разработчика, но я возражу, что, например, неделя для js — вызывает butthurt в 146% случаев, и подводить к такому спорному решению — зло.
Я с трудом могу представить себе систему в которой контент не меняется динамически. Homepage?
Я не считаю себя крупным серdиcом, у меня всего 10 картинок на амазоне лежит, однако пути к ним все s3-eu-west-1.amazonaws.com/foo-bar/magnify.jpg?1350015777. А браузер пусть сам запоминает видел ли он эту картинку или нет.
Весь html динамический, кэш отдает сервер приложений, потому, как веб-сервер не может знать, изменились ли данные объекта и, соотвественно, изменилось ли содержимое представления.
Веб серверу нельзя управлять кешированием! Однако, веб сервер должен уметь читать заголовки в которых ему четко и ясно скажут, что свежак, а что 304.
Header set Cache-Control «max-age=2592000»
А я вот тут картинки обновил на сервере. У пользователя они будут через месяц?
Js на неделю? у меня 3-4 выкатки на staging в день, большая часть касается js css
Html на день?
Да что такое, почему? Почему вы предлагаете ограничить возможность изменения данных на уровне веб сервера?
Я считаю эти рынки разными. Разработку я веду в убунте, игрульки у меня на винде, а о маке я мечтаю.
iOS-ы ставится на Apple, Windows8 на Windows 8 Ready, Ubunty на Ubuntu Ready. Я вижу здесь не проблему, а разные рынки.
Однако, это означает лишь то, что невозможно предсказать эти флуктуации статистическими методами.
Во вторых, «почти случайные» синонимичны «псевдослучайным» сигналам в данном контексте.
Даже если генерировать псевдослучайные сигналы взять за основу «белый шум», некорректно говорить о случайности.