Макс

Реддит и хакер ньюс это хорошо, но если голый проект без описания, вряд ли кто-то полезет его даже пробовать, хотя звездочек могут понаставить.

1. Подготовьте проект
- хороший README важен критически. Сделайте его понятным для дебилов. Примеры, обязательно примеры использования! Как скачать/скомпилить/слинковать проект - обязательно разбор по шагам, не пропуская ничего "очевидного"

- если это библиотека - обязательно хорошие доки!!

- если что-то связано с графикой, приложениями, играми - обязательно скриншоты

- явно пропишите лицензию. На Апач/Мит/бсд реакция живее, чем на gpl, учтите

- semver.org. версии оформляйте как "релизы" на гитхаб.

2. Статьи, с описанием фишек проекта, углубление в кейсы, разбор кишок проекта, инженерные наблюдения, журнал разработки. то есть - блог. Можно на том же гитхабе блог захостить, можно на блогспоте. Еще есть вариант - хостить на профильном сайте, типа dzone, infoq, html5rocks, и т. д. Плюс в том, что на эти сайты можно кинуть опопсенный рерайт статьи из основного блога, т.е. без особых усилий.

3. Пиар
- кидаем ссылки в реддит, хакер ньюс и профильные ньюс группы/форумы/гугл-плюс сообщества.
а) при публикации проекта
б) каждом релизе
в) каждом блог посте.
"Наглеть" можно, пока плюсуют на реддите.

- Еще, киньте ссылку в твиттер, и попросите (отдельным меншионом) какого-нибудь пиаристого чувака ретвитнуть. Можно завести твиттер проекта для этого.

4. Работа с сообществом.
- Принимайте пулл-реквесты, даже если они вам не 100% нравятся. Лучше принять и поправить потом.
- заведите гугл-группу для вопросов, сошлитесь на нее в Ридми, КРУПНО.

Это называется переменная с переменным именем (variable variable).

class Foo {
  public $deepest = 'Limbo';
  
  public function __toString()
  {
    return 'deep';
  }
}

$deeper = 'deepest';
$deep = 'deeper';
$b = new Foo();

echo $b->$$$b;

Выражение выполняется справа налево:
1. $b->$$($b) превращается в $b->$$($b->__toString()), поскольку именно так ведут себя объекты, когда на них пытаются натравить echo;
2. $b->$$($b->__toString()) превращается в $b->$(${'deep'}), именно это значение возвращает метод __toString класса Foo, инстансом которого является $b;
3. $b->$(${'deep'}) превращается в $b->$($deep), это как раз вызов переменной при помощи значения из другой переменной;
4. $b->$($deep) превращается в $b->${'deeper'}, поскольку именно такое значение находится в переменной $deep;
5. $b->${'deeper'} превращается в $b->($deeper);
6. $b->($deeper) превращается в $b->deepest;
7. наконец, получается значение свойства 'deepest' из $b, а там как раз хранится 'Limbo', оно и выводится в echo.

- Symfony2 (symfony.com)
- Sylius (sylius.org , https://github.com/Sylius) Symfony2 eCommerce

В collection2 слушаете событие add (оно встроенное) на collection1. В обработчик первым аргументом придет как раз добавленная модель. Однако, ее нельзя просто добавить в collection2 (она исчезнет из collection1), надо делать this.add(model.clone()).

Лучше разбейте на три коллекции. У вас будет одна модель, одна коллекция, view на модель, view на коллекцию и какая то внешняя разметка с логикой прокрутки коллекций (карусель какая-нибудь).

По личному опыту реализации Rich-frontend'ов могу сказать что тут есть несколько важных моментов про которые частенько забывают - в backbone-подобных фреймворках часто наблюдаются утечки памяти при интенсивных загрузках / обновлении контента. Был опыт реалзизации проектов где "все в одном JS и html файлике" в буквальном смысле, с обновлением контента в реальном времени через socket.io... и там утечки памяти были основной проблеммой.

Пробовал knockout, ember, meteor, spine, backbone... но вот лучше всех себя в этом плане показал Angular, хотя принципы и скорость рендеринга в нем пока что оставляют желать лучшего. Есть на свете минимум 2-3 форка (ремейка) backbone которые призваны спасти своего прародителя от утечек.

Из истории: twitter как-то реализовал весь свой сервис подобным образом, через время им пришлось разбить все постранично, что бы форсировать сборку мусора.

Вот в rest интерфейсах меня больше всего сейчас волнует отсутствие нормальной поддержки http кеширования - поддержки тегов if-modified-since, и etags.
Из того что есть ... есть restangular и он очень сырой. Встроенный в angular resource модуль, пока очень сильно порезан, и ему конкретно не хватает фич, но для ваших задач должно хватить.

Не уверен что angular будет оправданным выбором в случае с single-page, возможно стоит взглянуть в сторону spine + handlebars / jade.

Некоторые жалуются на высокий порог вхождения angular, хотя мне показалось что там все довольно просто и документация довольно хороша. Он мне показался даже проще Backbone. Но на вкус и цвет...

1. Да
2. Нет. Если Вам нужен качественный, быстрый, и лёгкий чат. И «Да», если вам не важны эти характеристики.
3. Я бы порекомендовал 2 фазную авторизацию. Когда на чат сервере — своя сессия. И он у симфонии (или наоборот) через RPC подвязывается сессия к пользователю.
4. Лучше сообщения держать в памяти чат сервера. Если вам нужны логи, или модэрация — то сообщения можно выгружать в Мускуль. Но читать их от туда (кроме случая с стартом чат сервера) смысла нет совершенно.

P.S. Примеров чат серверов и на longPooling, и на webSocket на node.js много. RPC реализаций — тоже. Прикрутить чат — дело пары часов (Вместе с кроссаутентификацией итп)

Не видел zend, но вот такое гуглится:

$route1 = new Zend_Controller_Router_Route_Regex(
                 ’blogs/id(.*)’,array(
                                           ‘action’ => 'ololo',
                                            ’controller’ => 'lololo',
                                             ‘module’ => 'default'),
                       array(1 => 'id'));
$route2 = new Zend_Controller_Router_Route_Regex(
                 ’blogs/post(.*)’,array(
                                           ‘action’ => 'lolo',
                                            ’controller’ => 'olol',
                                             ‘module’ => 'default'),
                       array(1 => 'id'));
$route3 = new Zend_Controller_Router_Route_Regex(
                 ’blogs/’,array(
                                           ‘action’ => 'lolo',
                                            ’controller’ => 'olol',
                                             ‘module’ => 'default'),
                       array());

Последний можно и без регекса конечно же, но лень искать еще.
А число потом получать так $this->getRequest->getParam('id')
А еще, может я со слешами натупил в регулярке.

Декодировать будет json_decode, и кириллицы она не боится.
А для json_encode просто добавьте JSON_UNESCAPED_UNICODE — и всё