Усложнится совсем на чуть чуть но это даст возможность работаь с сайтом и без nginx — более высока я переносимость, хотя если в этом нет необходимости — то и смысла делать нет.
Я полностью согласен с Вашим методом.
minify каждый раз отдет статику через себя, т.е. его надо к кэшу пркручивать, но как Вариант — вполне.
Мне не очень понравился потому как у меня в движке еще масса всего делается при формировании кэша статики да и процесс хотелось бы контролировать. Кроме того по поводу минификации YUI или же Closure Compiller жмет гораздо лучше.
Согласен. Там действительно проще это сделать.
Однако насчет «не будет эффекта» — не соглашусь — если Апач у Вас ОДИН раз подготовит статику в определнном месте, а потом из этого места ее отдает nginx — ничего в плане быстродействия Вы не потеряете.
ob_gzhandler к сожелению ориентируется только на основании заголовка Accept-Encoding, об этом тоже в хелпе есть. Увы и ах — этого не всегда достаточно, например для конкуер (а также IE5/IE6).
Про nginx — господа, если на фронтэнде у Вас торчит nginx — это круто, действительно круто, но во-первых вся эта методика подходит и для него, во вторых обычно бэкэнд у него — Апач.
По этому не очень уместно спорить здесь в ключе «Камаз конечно хорошо, но вот бэха! Бэха гораааздо круче» :)
Обычно nginx есть у VDS а не у простых хостингов, а VDS — совсем другая песня — я про это упоминалу уже )
Про YUI & Google Closure — естественно JS как и CSS надо оптимизировать через них (я например использую YUI)
Но здесь я рассказывал немного не об этом, не так ли? Можно было конечно и упомянуть минимизацию, но я считаю чтобы не было сумятицы — котлеты отдельно, мухи отельно.
Минимайзеры — это вообще тема для отедльной статьи.
Так, и вот самое интересное — для меня очень интересное, как господа у которых сборка проекта осуществляется через запуск спец скриптов (например через шелл).
Как применить тотже YUI или другие утилиты — это вполне понятно, непонятно одно — как Вы определяете КАКИЕ файлы для КАКОЙ странички склеивать?
Т.е. во-первых как у Вас подключаются склеиваемые скрипты на страничках, во вторых, как вы узнаете для каокй страницы какие скрипты склеивать?
У меня сделать это както хорошо, чтобы не мозолило глаза — увы — не получилось. Поделитесь опытом? Буду очень признателен.
Вот такой метод мне как раз не нравится… хотя бы тем, что в описанном здесь случае чтобы сделать из ветки дев ветку продакшен достаточно просто поменять одну константу :)
Это если локально то да, просто ИМХО когда любой пользователь необходим ресурсу начинаешь задумываться об этом.
Из практики про непользовательские прокси могу рассказать что знаю контору у которых стоит Squid режущий все заголовки кроме базовых — с точки зрения админа это типа «безопасно» + «многие дурацкие сайты не работают» :-D
На самом же деле вопрос намного сложнее, чем ответ.
Разные способы — разные риски.
На мой взгляд самое надежное — запрашивать пароль перед какойлибо «опасной» процедурой.
И в случае если пользователь очень важен ресурсу то больше не проверять ничего. ИМХО.
содержимое $_SESSION не хранится в куках, в куках хранится лишь id сессии, к тому-же это всеголишь пример. Чтобы ничего не ломалось в тойже статье описан способ когда токен выдается на определнное время — что делает этот способ вполне корректным.
Referer увы и ах не панацея — может резаться как проксями так и не выдаваться браузерами, и да,
можно сколько угодно говорить что виноват пользователь :-D
Есть еще один интересный подход, позаимствованный со спектрыма еще, когда бэкбуферов два — один для динамики, второй для фона ( фон медленней меняется чем динамика — например пероснаж и объекты вокруг него — оотвтественно все это отрисовывается в разных потоках ) — при выводе сначала выводится бэкбуфер с фоном потом сверху бэкбуфер с динамикой.
По поводу 1 игра != 1 canvas добавлю от себя, что самый простой и быстрый вариант — это старый добрый спрайтовый подход.
При запуске игры нагенерили спрайты с которыми дальше будете работать, отрисовали их в бэк-буфере ( можно или бак-канвас или imageData ), выкинули на экран и т.д. По сравнению с простой отрисовкой на канвасе скорость получается гораздо более привлекательная
С точки зрения логики да, но работаь с этим делом не удобно. В конце концов это свойство должно влиять на визуальный вид объекта
Я не говрю спецальные какието свойства, которые могут быть присвоены с помощью JS
Или тогда надо делать чтото наподобии CSS но для свойств объекта.
Вообще путаница эта очень давно. теже cellspacing-и и cellpadding-и и т.д.
Ну а если JQ давала возможность свести все это к одной фии — это и было хорошо — потому и одумались.
Так то оно так, однако оно на самом деле сказывается на виде документа — т.е. у тогоже чекбокса галочка появляется. Мне кажется что не было бы ничего страшного убрать это все в css.
Я полностью согласен с Вашим методом.
Мне не очень понравился потому как у меня в движке еще масса всего делается при формировании кэша статики да и процесс хотелось бы контролировать. Кроме того по поводу минификации YUI или же Closure Compiller жмет гораздо лучше.
Однако насчет «не будет эффекта» — не соглашусь — если Апач у Вас ОДИН раз подготовит статику в определнном месте, а потом из этого места ее отдает nginx — ничего в плане быстродействия Вы не потеряете.
А по поводу подключения к index.html — окей, а к другим страницам сайта? Или у Вас все скрипты всегда подключаются ко всем страницам?
Про nginx — господа, если на фронтэнде у Вас торчит nginx — это круто, действительно круто, но во-первых вся эта методика подходит и для него, во вторых обычно бэкэнд у него — Апач.
По этому не очень уместно спорить здесь в ключе «Камаз конечно хорошо, но вот бэха! Бэха гораааздо круче» :)
Обычно nginx есть у VDS а не у простых хостингов, а VDS — совсем другая песня — я про это упоминалу уже )
Про YUI & Google Closure — естественно JS как и CSS надо оптимизировать через них (я например использую YUI)
Но здесь я рассказывал немного не об этом, не так ли? Можно было конечно и упомянуть минимизацию, но я считаю чтобы не было сумятицы — котлеты отдельно, мухи отельно.
Минимайзеры — это вообще тема для отедльной статьи.
Так, и вот самое интересное — для меня очень интересное, как господа у которых сборка проекта осуществляется через запуск спец скриптов (например через шелл).
Как применить тотже YUI или другие утилиты — это вполне понятно, непонятно одно — как Вы определяете КАКИЕ файлы для КАКОЙ странички склеивать?
Т.е. во-первых как у Вас подключаются склеиваемые скрипты на страничках, во вторых, как вы узнаете для каокй страницы какие скрипты склеивать?
У меня сделать это както хорошо, чтобы не мозолило глаза — увы — не получилось. Поделитесь опытом? Буду очень признателен.
:(
Из практики про непользовательские прокси могу рассказать что знаю контору у которых стоит Squid режущий все заголовки кроме базовых — с точки зрения админа это типа «безопасно» + «многие дурацкие сайты не работают» :-D
На самом же деле вопрос намного сложнее, чем ответ.
Разные способы — разные риски.
На мой взгляд самое надежное — запрашивать пароль перед какойлибо «опасной» процедурой.
И в случае если пользователь очень важен ресурсу то больше не проверять ничего. ИМХО.
Referer увы и ах не панацея — может резаться как проксями так и не выдаваться браузерами, и да,
можно сколько угодно говорить что виноват пользователь :-D
В кратце все просто — для каждой формы или опасного действия грубо делается следующее (PHP):
<?php
session_start();
if ( @$_SESSION['token'] && @$_POST["token"] ) {
if ( $_SESSION["token"] == $_POST["token"] ) {
обработка формы
}
}
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>
<form ...>
....
<input type="hidden" name="token" value="<?php echo( $token ); ?>"
</form>
При запуске игры нагенерили спрайты с которыми дальше будете работать, отрисовали их в бэк-буфере ( можно или бак-канвас или imageData ), выкинули на экран и т.д. По сравнению с простой отрисовкой на канвасе скорость получается гораздо более привлекательная
А неудобство в том что есть две сущностии с ними надо както работать по разному.
Я не говрю спецальные какието свойства, которые могут быть присвоены с помощью JS
Или тогда надо делать чтото наподобии CSS но для свойств объекта.
Вообще путаница эта очень давно. теже cellspacing-и и cellpadding-и и т.д.
Ну а если JQ давала возможность свести все это к одной фии — это и было хорошо — потому и одумались.