Про 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.
Просто частенько (Не в Вашем случае а вообще) такие вещи могут быть из-за плохой орагнизации модели (неграмотное проектирование), которая потом переложена на функционал.
Здесь согласен, но ИМХО при простой иерархии проще читаемо и поддерживаему всетаки функциональное программирование — я не про неймспейсы или чтото другое, а про то, что ради простой задачи где можно обойтись несколькими функциями нет смысла делать ООП вообще. зачем?
Про 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 давала возможность свести все это к одной фии — это и было хорошо — потому и одумались.
чем checked хуже display?
тем что установлено не через стиль?
И смысла ИМХО разграничивать тоже никакого не было. Ну и вот — отрефакторили :)
Почему интересно?
Так вроде вполне — цена около 319$
a) задачи
б) специалиста
Надо применять разные подходы в заисимости от задачи.
А дальше дело за тем как это будет реализовывать выбранный специалист.
Просто частенько (Не в Вашем случае а вообще) такие вещи могут быть из-за плохой орагнизации модели (неграмотное проектирование), которая потом переложена на функционал.