Было бы намного эффектнее, если бы точки разлетались равномерно в разные стороны (вероятность вектора начальной скорости равномерна по верхней полуокружности). Можно, впрочем, добавить некоторую часть от текущей скорости юнита, чтобы был эффект продолжающегося движения.
Нищебродство, вот как это называется.
Уже 5 лет работаю только на зарубежных биржах (расценки там в разы выше), так вот, абсолютно все биржи запрещают обмен контактами в приглашении (bid) и абсолютно все биржи работают только через Escrow (безопасная сделка). Да, приходится платить проценты, 6% с каждого проекта. Да, приходится покупать платный аккаунт ($10 в месяц). Но поверьте — всё это ничто по сравнению с защитой от мошенничества, которую это даёт.
Товарищ, религия и вера — вещи очень разные, порой диаметрально противоположные. Вера возникает внутри человека и её невозможно поколебать каким-то фильмом. А вот религия — это инструмент воздействия на толпу и тут всякое инакомыслие чревато.
Вот вам как это делает гугль: developers.google.com/webmasters/ajax-crawling/docs/getting-started
при желании можете поискать как это делают другие поисковики (но лично мне кажется, что примерно так же).
Что касается шаблонизатора — не имеет никакого значения какой он, поскольку HTML берётся с сервера уже готовый, в обход клиентской инфраструктуры.
Не вижу никаких проблем, гугль и другие поисковики уже умеют индексировать ajax-сайты, причём делают это достаточно хитро: по имеющейся «ajax-ссылке» (что-то вроде mysite.ru/#!/link/89) они формируют нормальную ссылку без хэша, по которой сервер отдаёт готовый HTML-слепок ajax-страницы.
Ваше заявление касается только случая, когда шаблоны обрабатываются в runtime, однако если шаблоны компилируемые (как в Smarty или как в Twig), то с большой вероятностью Вы не сможете вручную сделать исполняемый код быстрее, чем код скомпилированного шаблона. Я уже не говорю о кэшировании, которое в случае шаблонизатора добавляется буквально двумя строками кода и сводит на нет «преимущества» приведённого Вами лапшекода.
Понятно, что демонстрационный. Но разве не должен демонстрационный сайт показывать всю мощь фреймворка? Потому что имхо такой «демонстрационный сайт» можно написать без всякого фреймворка и даже оптимальнее…
Что-то новое всегда интересно, но вот наличие в классах страниц (VGS_GuestBook.java) низкоуровневых методов, считывающих побайтно какие-то файлы и раскладывающие их в переменные переносит меня мысленно во времена exe-файлов, работающих под CGI и написанных на Delphi.
Несмотря на то, что V8 скорее всего по-любому шустрее Zend, о быстродействии тут речи не идёт. Суть в концепции построения приложения. В конце концов, если быстродействие будет так важно, мы напишем всё на С++.
Лет 8 назад я писал однопоточный демон на PHP с помощью socket_select() (мне нужен был клиент для iChat с постоянным коннектом, реализующий несложную текстовую игру). Работало это достаточно шустро и надёжно, перегружал этого демона не чаще раза в неделю. Я и подумать не мог, что именно эта технология через несколько лет станет популярной и начнёт набирать обороты.
Кстати написать нечто подобное с нуля может любой средний программер на PHP, это может быть полезно, например, для того, чтобы «на берегу» разобрать все тонкости работы с таким демоном. Как Вы понимаете, в nodejs по сути реализовано то же самое, просто больше библиотек и пафоса.
Если кто-то пропустил, то можно прямо сейчас посмотреть асинхронный фреймворк на php, называющийся phpDaemon. Если запустить его в один воркер, то получится в точности однопоточный nodejs. Так что любители синтаксиса php могут опробовать асинхронность прямо сейчас, не переучиваясь на js.
Кстати говоря, phpDaemon также весьма шустр.
Кстати говоря (часть 2): асинхронный код на php очень сильно отличается от «обычного» php-кода. «Вроде функции те же, а чё написано не понятно».
Вот уже 5 лет я использую следующий простой принцип:
1. Тэг form ничего никуда отправляет, он служит скорее для группировки полей, но в принципе можно обойтись и без него. Очень часто я использую div — это не имеет большого значения.
2. По событию нажатия на submit (или какому-то другому — для сложных форм) js собирает данные из контролов и отправляет их на адрес обработчика с помощью ajax.
3. Обработчик на PHP (каждая форма считается объектом и у него есть просто метод onFormSubmit()) анализирует данные и через JSON возвращает последовательность простых команд по дальнейшей работе клиента. Это могут быть: подсветить поле(-я), вывести alert, сделать редирект, выполнить js-код или обновить кусок DOM. Редирект не делается только в том случае, если есть ошибки в форме и надо повторить отправку после их исправления.
Куда делать редирект — решает сам контроллер, и это, я считаю, правильно. Сам клиент ничего не валидирует и не принимает никаких решений (валидация на клиенте бессмысленна), а просто следует командам сервера.
Уже 5 лет работаю только на зарубежных биржах (расценки там в разы выше), так вот, абсолютно все биржи запрещают обмен контактами в приглашении (bid) и абсолютно все биржи работают только через Escrow (безопасная сделка). Да, приходится платить проценты, 6% с каждого проекта. Да, приходится покупать платный аккаунт ($10 в месяц). Но поверьте — всё это ничто по сравнению с защитой от мошенничества, которую это даёт.
при желании можете поискать как это делают другие поисковики (но лично мне кажется, что примерно так же).
Что касается шаблонизатора — не имеет никакого значения какой он, поскольку HTML берётся с сервера уже готовый, в обход клиентской инфраструктуры.
Кстати написать нечто подобное с нуля может любой средний программер на PHP, это может быть полезно, например, для того, чтобы «на берегу» разобрать все тонкости работы с таким демоном. Как Вы понимаете, в nodejs по сути реализовано то же самое, просто больше библиотек и пафоса.
Кстати говоря, phpDaemon также весьма шустр.
Кстати говоря (часть 2): асинхронный код на php очень сильно отличается от «обычного» php-кода. «Вроде функции те же, а чё написано не понятно».
1. Тэг form ничего никуда отправляет, он служит скорее для группировки полей, но в принципе можно обойтись и без него. Очень часто я использую div — это не имеет большого значения.
2. По событию нажатия на submit (или какому-то другому — для сложных форм) js собирает данные из контролов и отправляет их на адрес обработчика с помощью ajax.
3. Обработчик на PHP (каждая форма считается объектом и у него есть просто метод onFormSubmit()) анализирует данные и через JSON возвращает последовательность простых команд по дальнейшей работе клиента. Это могут быть: подсветить поле(-я), вывести alert, сделать редирект, выполнить js-код или обновить кусок DOM. Редирект не делается только в том случае, если есть ошибки в форме и надо повторить отправку после их исправления.
Куда делать редирект — решает сам контроллер, и это, я считаю, правильно. Сам клиент ничего не валидирует и не принимает никаких решений (валидация на клиенте бессмысленна), а просто следует командам сервера.