Pull to refresh

Comments 87

Можно было бы еще попробовать какой-нибудь более подходящий язык.
Node.js ничем не лучше Ruby/Python, кроме своей новизны (и малоизвестности багов).
Говорят, что он лучше тем, что все и так знают его синтаксис. Но это критически неправильная штука, потому что для систем 24/7 (в отличие от окошка браузера) нужна совершенно другая парадигма. В Эрланге она есть, в других более-менее известных системах её нет.
Ну да, не на javascript же асинхронный код писать :)
Спасибо за интересную статью!

В последнее время интересных развёрнутых статей на Хабре совсем мало.
Для реалтайм приложений с push нотификациями, на мой взгляд, намного более удобен node.js, или ruby с EventMachine, или python с Tornado, нежели ZendFramework и сторонний сервер.

Объясните, пожалуйста, почему вы выбрали именно ZendFramework для такой нетипичной для него задачи?
Какие недостатки вы видите в названных мною решениях?
Прекрасные решения, особенно node.js
ZeroMQ — это всётаки транспорт, а не готовое решение для организации очередей, как то же ActiveMQ.
Ну да, кстати было бы удобнее висеть например mod_perl или FastCGI скрипту постоянно не подгружаясь каждый раз как PHP скриптам, хотя в версии 5.3 вроде уже реальный FastCGI сделали, а в довесок eAccelerator бы помог на необходимости перекомпилировать скрипты.

Кстати, почему бы не использовать в этом случае Flash, там же есть сокеты?
А где ссылка на проект или дата релиза, может прогледел?
спасибо, опасаетесь хабраэффекта?
Чорт, спалили :-) Да, на самом деле страшновато.
Вариант с семаформи было бы неплохо реализовать в nginx.
UFO landed and left these words here
c WebSocket много проблем
nginx например их не поддерживает
UFO landed and left these words here
UFO landed and left these words here
1. Мне кажется никто не будет уныло торговать лицом пялясь в пустой экран/на лидера, дожидаясь своей очереди
2. Для каждой задачи как правило существуют специально написанные для решения подобных задач инструменты. Flex+Cirrus — обладают всем необходимым инструментарием. Буквально пару эранов кода для вещания/очередей.
Я бы начал с анализа того как бы сделать проект таким, чтобы он «зажигал», потом считал бы сколько надо денег на содержание и раскрутку, анализировал рынок/конкурентов, искал способы монетизации, потом долго выбирал бы необходимый мне инструмент (среди всех технологий а не из 5 известных мне на данный момент) и только потом (и то врятли) приступил бы к реализации.
А вы слишком драйвовые )
ЗЫ: картинки на салфетках понравились
Кстати если бы провели анализ конкурентов — video.mail.ru/broadcast то увидели бы что:
1. Именно на Cirrus и делаются подобные проекты
2. На первом месте сиськи
3. Монетизации нет вообще
4. Затраты существенные
О чем вы думали когда его разрабатывали?
Нет, мне правда интересно, одно дело когда школьник пишет прокси для яндекс робота и называет это стартапом, и совсем другое — солидная студия, вложена куча ресурсов, зачем? Для портфолио?
В первом абзаце же написано:
молодой парень, с амбициозной идеей и “средствами для реализации” в кармане.

А студия выполняет заказ :)
О, привет
Как с мафией дела? Выстрелила идея?
Заморозилась пока :)
Возьму на себя смелость с вами не согласиться. Долго анализировать и продумывать все мелочи и детали — пагубная практика. Предусмотреть все в проекте, которого еще нет — задача удивительно сложная (если не сказать — нереальная). Если есть хорошая идея, надо ее на энтузиазме делать. Прям брать и делать. Если выстрелит — в быстром темпе дорабатывать, исправлять ошибки.
А анализировать можно всю жизнь. Так ничего не добиться.
Я так отвечу — жизнь коротка и каждый сам выбирает на что её потратить.
бородатый мужчина суперзвезда =) надо вам стриптизершу нанять =)
GAE, простенький Backend и Channel API
Контент по идее должен быть:
1. Сисечный — соревнования между сисюльками, кто на что способна
2. Юморной — в соревновании юмористы кажется могут вполне себе чудить неплохо… хотя хз хз ну или
3. Музыкальный (хоум выступления а ля ютьюб)
Голосовать рублем — небольшими суммами в сторону + и обычными вируальными минусами в сторону минус :)
Согласен. Мне кажется, это как раз тот случай, когда стартапу не хватает бабла. Сделать много шумихи, привлечь юзеров и замутить что-то типа камедиклабского ринга.
Спасибо, так с чата я давное не смеялся =)
UFO landed and left these words here
Спасите нас от гитариста
UFO landed and left these words here
Интересная идея и хорошая реализация. Если не секрет, то сколько по времени заняла разработка и какой примерный бюджет. Приблизительных цифр будет достаточно, я не выпытываю информацию об этом сайте, а прицениваюсь к вашим услугам :)
И мне тоже, пожалуйста!
А почему вы не рассматривали Redis для организации очереди? Есть и интеграция в ZF (Rediska), и стабильность.
Почему для рассылки сообщение не использовался jabber?
И да. Я ща решил освоить пхп-шный фрэймворк. Первый в моей жизни: о) Почитал немного про них и остановился на CakePHP. Можете прокомментирвоать, почему вы выбрали именно Zend?
Я не тот у кого вы спрашивали, но:
1. Разрабатывается компанией Zend, являющейся разработчиком самого PHP.
2. Сотни тысяч компонентов, интеграция с чем угодно.
3. Приемлемая легкость освоения и гибкость.
Пожалуйста, выберите фреймворк, который написан на последней версии PHP. Ну зачем в 2011 году учить старый Cake?
Плохо что разные люди могут писать под одним именем.
Не хочу обидеть, но… мне кажется прежде чем делать проект с названием «Feel You Star» неплохо было бы посоветоваться с носителем английского языка. Носитель, возможно, сказал бы вам что это словосочетание звучит нелепо и неправильно и ничего толком не значит.
Ага, именно так и сказал носитель языка.
Зашел на ваш проект и пока я вижу, что это хорошая голосовалка по порно. Там уже минут 15 девушка за инвайт делает такое…
Волей-неволей зашел на сайт снова…
Женские прелести в самых развратных формах.
Лепра бэк, блин. Но скрины надо было сохранить )
Коллеги. Вы молодцы, что это всё сделали, но было бы гораздо лучше написать это сразу на erlang, или хотя бы на ruby/python.

Хотя бы — потому что на ruby/python/node.js вы бы собрали всего лишь чуть меньшее количество граблей, чем на erlang, а у вас классическая задача, которую с самого начала надо было прототипировать и решать на erlang.
я сам хотел написать это со ссылкой на ваш проект) А как вы порекомендовали бы решать задачи с очередями в эрланге?
1) под каждого пользователя делается отдельный эрланговый процесс
2) процессы регистрируются в накопителе сообщений
3) накопитель сообщений представляет из себя процесс с банальным списком сообщений
4) клиентский хендлер умеет получать от клиента номер последнего полученного сообщения (erlang:now() гарантированно монотонно растет — прекрасный способ идентифицировать сообщения)
5) накопитель умеет отдавать все сообщения старше нужного.
6) старые сообщения со временем удаляются.

Всё. Одна простая деталь вместо трех сложных. Демон на C++ будет в реализации сложнее вашего решения, потому что вы потонете в менеджменте памяти и строк.

Основная прелесть в том, что это всё будет прекрасно работать и с очень большим ростом количества клиентов. Решения на ruby/python/node.js в какие-то моменты начнут магически глючить и отваливаться.
Прям готовая подпись «1 инвайт в лицо» )))
Ужос. Придется прикрутить модерацию.
угу. Побольше такого годного контента.
А мы от Comet-ы пошли к XMPP (strohpe.js библиотечка).
Хотя (лично я) предпочитаю websocket-ы — как более простая реализация со стороны клиента. Жаль, что количество браузеров ограничено.

С другой стороны strophejs — тоже не лишена недостатков. Есть определённые флешовые приколы с IE/Opera :(
Дождались бы пятницы. Мне диплом нужно делать!
ActiveMQ довольно непредсказуемо себя ведет, вешается, лочится и т.п. Отчасти помогает отключение сохранения сообщений, но только отчасти. Гугление проблем приводит к багам, которые не закрыты или не воспроизведены по несколько лет.

Выбранная вами архитектура представляется хрупкой и непредсказуемой, имеет смысл все же рассмотреть вариант использования неблокирующего сервера типа на node.js, tornado, twisted и т.п.
Эрланговский RabbitMQ хорошо себя ведёт.
Скажите, пожалуйста, а чем вы такие красивые схемки рисовали?
чего только люди не делают, чтобы не писать мааленький простенький демон на с++
Круто. Изменять можно чуть-чуть.

Нужно чтоб голосование было открытым — видно кто плюсует, кто минусует,
нужно призывать пользователей задавать вещателю задания, а голосовать
по принципу понравилось или нет…

получившиеся видео вместе с чатом за этот период будет представлять какой-то
законченный контент… его можно хранить если контент чем-то хорош :)
А в чём схемы рисовали? Или ручками все?
Для реализации очередей ещё можно использовать Starling. Как раз недавно использовал его для совместной работы Ruby и ZF.
И антиспам в чат надо встроить однозначно. А вообще идея клёвая, реализация тоже — молодцы!
срочно нужен антиспам простенький. засирают флудом чат, уроды(
Вот-вот. Зашел поглядеть на сайт — в чате одни «сиськи, дайте подрочить!», «главное вовремя кончить» и подобные вещи.
Подскажите, а в чем вы схемки рисовали?
Зашел на сайт — решил поглядеть, что за зверь получился.
Что увидел — «стар'ы» показываются на экране не более 1-2 секунд, а в промежутках между показами висит надпись «Waiting for a New Star». Ну и толпы троллей и дрочеров в чате, ожидающих, когда же там опять на парочку секунд покажут «девушку с буферами».
Уважаемые авторы, если я все правильно понял — то вы пошли по неправильному пути, используя апач для PUSH-запросов. Он создает отдельный поток на каждый HTTP-запрос, очень плохо, поскольку каждый висящий поток — это занятая память, а создание нового потока — процессорные ресурсы.

Для решения вашей задачи нужен сервер, который обрабатывает все запросы в одном потоке, например node.js (есть отличный проект socket.io — посмотрите) или APE. Оба проекта довольно активно развиваются и заявляют о высокой нагрузке. Кроме того, у них есть уже написанная серверная и клиентская части, так что вам не надо изобретать велосипед. На мой взгляд использовать одну из них лучше, чем Flash/Cisrrus, по следующим причинам:

— Более простая архитектура клиентской части (только JS, flash — только для видео)
— Должно быстрее работать (не надо грузить и инициализировать флеш, и код может быть легче)
— Возможно, будет выше производительность (не проверял, надо тестить)
Скажите, а что для реализации Comet вы выбрали (из приведеного по ссылке обзора или чего-то иного)?
Only those users with full accounts are able to leave comments. Log in, please.