Comments 87
Можно было бы еще попробовать какой-нибудь более подходящий язык.
+8
Node.js :-)
+6
Node.js ничем не лучше Ruby/Python, кроме своей новизны (и малоизвестности багов).
+2
Erlang :-)
+11
Спасибо за интересную статью!
В последнее время интересных развёрнутых статей на Хабре совсем мало.
В последнее время интересных развёрнутых статей на Хабре совсем мало.
+3
Для реалтайм приложений с push нотификациями, на мой взгляд, намного более удобен node.js, или ruby с EventMachine, или python с Tornado, нежели ZendFramework и сторонний сервер.
Объясните, пожалуйста, почему вы выбрали именно ZendFramework для такой нетипичной для него задачи?
Какие недостатки вы видите в названных мною решениях?
Объясните, пожалуйста, почему вы выбрали именно ZendFramework для такой нетипичной для него задачи?
Какие недостатки вы видите в названных мною решениях?
+6
ZeroMQ не рассматривали?
+1
ZeroMQ — это всётаки транспорт, а не готовое решение для организации очередей, как то же ActiveMQ.
-1
Нет
-1
Не так это слово пишется. А вот как: RabbitMQ.
Вот как Second Life выбирал себе сервер очередей:
wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
Вот как Second Life выбирал себе сервер очередей:
wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
+1
Ну да, кстати было бы удобнее висеть например mod_perl или FastCGI скрипту постоянно не подгружаясь каждый раз как PHP скриптам, хотя в версии 5.3 вроде уже реальный FastCGI сделали, а в довесок eAccelerator бы помог на необходимости перекомпилировать скрипты.
Кстати, почему бы не использовать в этом случае Flash, там же есть сокеты?
Кстати, почему бы не использовать в этом случае Flash, там же есть сокеты?
0
А где ссылка на проект или дата релиза, может прогледел?
0
Откройте указанный сайт студии и посмотрите портфолио: www.sibirix.ru/portfolio/site/razrabotka-servisa-feel-you-star.htm
0
Вариант с семаформи было бы неплохо реализовать в nginx.
0
UFO just landed and posted this here
UFO just landed and posted this here
1. Мне кажется никто не будет уныло торговать лицом пялясь в пустой экран/на лидера, дожидаясь своей очереди
2. Для каждой задачи как правило существуют специально написанные для решения подобных задач инструменты. Flex+Cirrus — обладают всем необходимым инструментарием. Буквально пару эранов кода для вещания/очередей.
Я бы начал с анализа того как бы сделать проект таким, чтобы он «зажигал», потом считал бы сколько надо денег на содержание и раскрутку, анализировал рынок/конкурентов, искал способы монетизации, потом долго выбирал бы необходимый мне инструмент (среди всех технологий а не из 5 известных мне на данный момент) и только потом (и то врятли) приступил бы к реализации.
А вы слишком драйвовые )
ЗЫ: картинки на салфетках понравились
2. Для каждой задачи как правило существуют специально написанные для решения подобных задач инструменты. Flex+Cirrus — обладают всем необходимым инструментарием. Буквально пару эранов кода для вещания/очередей.
Я бы начал с анализа того как бы сделать проект таким, чтобы он «зажигал», потом считал бы сколько надо денег на содержание и раскрутку, анализировал рынок/конкурентов, искал способы монетизации, потом долго выбирал бы необходимый мне инструмент (среди всех технологий а не из 5 известных мне на данный момент) и только потом (и то врятли) приступил бы к реализации.
А вы слишком драйвовые )
ЗЫ: картинки на салфетках понравились
0
Кстати если бы провели анализ конкурентов — video.mail.ru/broadcast то увидели бы что:
1. Именно на Cirrus и делаются подобные проекты
2. На первом месте сиськи
3. Монетизации нет вообще
4. Затраты существенные
О чем вы думали когда его разрабатывали?
Нет, мне правда интересно, одно дело когда школьник пишет прокси для яндекс робота и называет это стартапом, и совсем другое — солидная студия, вложена куча ресурсов, зачем? Для портфолио?
1. Именно на Cirrus и делаются подобные проекты
2. На первом месте сиськи
3. Монетизации нет вообще
4. Затраты существенные
О чем вы думали когда его разрабатывали?
Нет, мне правда интересно, одно дело когда школьник пишет прокси для яндекс робота и называет это стартапом, и совсем другое — солидная студия, вложена куча ресурсов, зачем? Для портфолио?
+1
Возьму на себя смелость с вами не согласиться. Долго анализировать и продумывать все мелочи и детали — пагубная практика. Предусмотреть все в проекте, которого еще нет — задача удивительно сложная (если не сказать — нереальная). Если есть хорошая идея, надо ее на энтузиазме делать. Прям брать и делать. Если выстрелит — в быстром темпе дорабатывать, исправлять ошибки.
А анализировать можно всю жизнь. Так ничего не добиться.
А анализировать можно всю жизнь. Так ничего не добиться.
+1
бородатый мужчина суперзвезда =) надо вам стриптизершу нанять =)
+3
GAE, простенький Backend и Channel API
0
Контент по идее должен быть:
1. Сисечный — соревнования между сисюльками, кто на что способна
2. Юморной — в соревновании юмористы кажется могут вполне себе чудить неплохо… хотя хз хз ну или
3. Музыкальный (хоум выступления а ля ютьюб)
Голосовать рублем — небольшими суммами в сторону + и обычными вируальными минусами в сторону минус :)
1. Сисечный — соревнования между сисюльками, кто на что способна
2. Юморной — в соревновании юмористы кажется могут вполне себе чудить неплохо… хотя хз хз ну или
3. Музыкальный (хоум выступления а ля ютьюб)
Голосовать рублем — небольшими суммами в сторону + и обычными вируальными минусами в сторону минус :)
+2
Спасибо, так с чата я давное не смеялся =)
0
UFO just landed and posted this here
Интересная идея и хорошая реализация. Если не секрет, то сколько по времени заняла разработка и какой примерный бюджет. Приблизительных цифр будет достаточно, я не выпытываю информацию об этом сайте, а прицениваюсь к вашим услугам :)
+2
А почему вы не рассматривали Redis для организации очереди? Есть и интеграция в ZF (Rediska), и стабильность.
+1
Почему для рассылки сообщение не использовался jabber?
0
И да. Я ща решил освоить пхп-шный фрэймворк. Первый в моей жизни: о) Почитал немного про них и остановился на CakePHP. Можете прокомментирвоать, почему вы выбрали именно Zend?
-1
Я не тот у кого вы спрашивали, но:
1. Разрабатывается компанией Zend, являющейся разработчиком самого PHP.
2. Сотни тысяч компонентов, интеграция с чем угодно.
3. Приемлемая легкость освоения и гибкость.
1. Разрабатывается компанией Zend, являющейся разработчиком самого PHP.
2. Сотни тысяч компонентов, интеграция с чем угодно.
3. Приемлемая легкость освоения и гибкость.
0
Пожалуйста, выберите фреймворк, который написан на последней версии PHP. Ну зачем в 2011 году учить старый Cake?
+2
Плохо что разные люди могут писать под одним именем.
0
Не хочу обидеть, но… мне кажется прежде чем делать проект с названием «Feel You Star» неплохо было бы посоветоваться с носителем английского языка. Носитель, возможно, сказал бы вам что это словосочетание звучит нелепо и неправильно и ничего толком не значит.
+1
А почему так тормозит?
+1
Зашел на ваш проект и пока я вижу, что это хорошая голосовалка по порно. Там уже минут 15 девушка за инвайт делает такое…
+2
Коллеги. Вы молодцы, что это всё сделали, но было бы гораздо лучше написать это сразу на erlang, или хотя бы на ruby/python.
Хотя бы — потому что на ruby/python/node.js вы бы собрали всего лишь чуть меньшее количество граблей, чем на erlang, а у вас классическая задача, которую с самого начала надо было прототипировать и решать на erlang.
Хотя бы — потому что на ruby/python/node.js вы бы собрали всего лишь чуть меньшее количество граблей, чем на erlang, а у вас классическая задача, которую с самого начала надо было прототипировать и решать на erlang.
0
я сам хотел написать это со ссылкой на ваш проект) А как вы порекомендовали бы решать задачи с очередями в эрланге?
0
1) под каждого пользователя делается отдельный эрланговый процесс
2) процессы регистрируются в накопителе сообщений
3) накопитель сообщений представляет из себя процесс с банальным списком сообщений
4) клиентский хендлер умеет получать от клиента номер последнего полученного сообщения (erlang:now() гарантированно монотонно растет — прекрасный способ идентифицировать сообщения)
5) накопитель умеет отдавать все сообщения старше нужного.
6) старые сообщения со временем удаляются.
Всё. Одна простая деталь вместо трех сложных. Демон на C++ будет в реализации сложнее вашего решения, потому что вы потонете в менеджменте памяти и строк.
Основная прелесть в том, что это всё будет прекрасно работать и с очень большим ростом количества клиентов. Решения на ruby/python/node.js в какие-то моменты начнут магически глючить и отваливаться.
2) процессы регистрируются в накопителе сообщений
3) накопитель сообщений представляет из себя процесс с банальным списком сообщений
4) клиентский хендлер умеет получать от клиента номер последнего полученного сообщения (erlang:now() гарантированно монотонно растет — прекрасный способ идентифицировать сообщения)
5) накопитель умеет отдавать все сообщения старше нужного.
6) старые сообщения со временем удаляются.
Всё. Одна простая деталь вместо трех сложных. Демон на C++ будет в реализации сложнее вашего решения, потому что вы потонете в менеджменте памяти и строк.
Основная прелесть в том, что это всё будет прекрасно работать и с очень большим ростом количества клиентов. Решения на ruby/python/node.js в какие-то моменты начнут магически глючить и отваливаться.
+4
Начало отличное
img.skitch.com/20110524-piwdnh229qjub7ttyxwsid5me3.jpg
надо уточнять что там за звезды :)
img.skitch.com/20110524-piwdnh229qjub7ttyxwsid5me3.jpg
надо уточнять что там за звезды :)
+1
А мы от Comet-ы пошли к XMPP (strohpe.js библиотечка).
Хотя (лично я) предпочитаю websocket-ы — как более простая реализация со стороны клиента. Жаль, что количество браузеров ограничено.
С другой стороны strophejs — тоже не лишена недостатков. Есть определённые флешовые приколы с IE/Opera :(
Хотя (лично я) предпочитаю websocket-ы — как более простая реализация со стороны клиента. Жаль, что количество браузеров ограничено.
С другой стороны strophejs — тоже не лишена недостатков. Есть определённые флешовые приколы с IE/Opera :(
0
Дождались бы пятницы. Мне диплом нужно делать!
0
ActiveMQ довольно непредсказуемо себя ведет, вешается, лочится и т.п. Отчасти помогает отключение сохранения сообщений, но только отчасти. Гугление проблем приводит к багам, которые не закрыты или не воспроизведены по несколько лет.
Выбранная вами архитектура представляется хрупкой и непредсказуемой, имеет смысл все же рассмотреть вариант использования неблокирующего сервера типа на node.js, tornado, twisted и т.п.
Выбранная вами архитектура представляется хрупкой и непредсказуемой, имеет смысл все же рассмотреть вариант использования неблокирующего сервера типа на node.js, tornado, twisted и т.п.
+1
Скажите, пожалуйста, а чем вы такие красивые схемки рисовали?
+1
чего только люди не делают, чтобы не писать мааленький простенький демон на с++
+2
Круто. Изменять можно чуть-чуть.
Нужно чтоб голосование было открытым — видно кто плюсует, кто минусует,
нужно призывать пользователей задавать вещателю задания, а голосовать
по принципу понравилось или нет…
получившиеся видео вместе с чатом за этот период будет представлять какой-то
законченный контент… его можно хранить если контент чем-то хорош :)
Нужно чтоб голосование было открытым — видно кто плюсует, кто минусует,
нужно призывать пользователей задавать вещателю задания, а голосовать
по принципу понравилось или нет…
получившиеся видео вместе с чатом за этот период будет представлять какой-то
законченный контент… его можно хранить если контент чем-то хорош :)
+2
Да ну, опять все дрочить будут.
0
А в чём схемы рисовали? Или ручками все?
0
Для реализации очередей ещё можно использовать Starling. Как раз недавно использовал его для совместной работы Ruby и ZF.
0
И антиспам в чат надо встроить однозначно. А вообще идея клёвая, реализация тоже — молодцы!
0
срочно нужен антиспам простенький. засирают флудом чат, уроды(
0
Подскажите, а в чем вы схемки рисовали?
0
Зашел на сайт — решил поглядеть, что за зверь получился.
Что увидел — «стар'ы» показываются на экране не более 1-2 секунд, а в промежутках между показами висит надпись «Waiting for a New Star». Ну и толпы троллей и дрочеров в чате, ожидающих, когда же там опять на парочку секунд покажут «девушку с буферами».
Что увидел — «стар'ы» показываются на экране не более 1-2 секунд, а в промежутках между показами висит надпись «Waiting for a New Star». Ну и толпы троллей и дрочеров в чате, ожидающих, когда же там опять на парочку секунд покажут «девушку с буферами».
0
Уважаемые авторы, если я все правильно понял — то вы пошли по неправильному пути, используя апач для PUSH-запросов. Он создает отдельный поток на каждый HTTP-запрос, очень плохо, поскольку каждый висящий поток — это занятая память, а создание нового потока — процессорные ресурсы.
Для решения вашей задачи нужен сервер, который обрабатывает все запросы в одном потоке, например node.js (есть отличный проект socket.io — посмотрите) или APE. Оба проекта довольно активно развиваются и заявляют о высокой нагрузке. Кроме того, у них есть уже написанная серверная и клиентская части, так что вам не надо изобретать велосипед. На мой взгляд использовать одну из них лучше, чем Flash/Cisrrus, по следующим причинам:
— Более простая архитектура клиентской части (только JS, flash — только для видео)
— Должно быстрее работать (не надо грузить и инициализировать флеш, и код может быть легче)
— Возможно, будет выше производительность (не проверял, надо тестить)
Для решения вашей задачи нужен сервер, который обрабатывает все запросы в одном потоке, например node.js (есть отличный проект socket.io — посмотрите) или APE. Оба проекта довольно активно развиваются и заявляют о высокой нагрузке. Кроме того, у них есть уже написанная серверная и клиентская части, так что вам не надо изобретать велосипед. На мой взгляд использовать одну из них лучше, чем Flash/Cisrrus, по следующим причинам:
— Более простая архитектура клиентской части (только JS, flash — только для видео)
— Должно быстрее работать (не надо грузить и инициализировать флеш, и код может быть легче)
— Возможно, будет выше производительность (не проверял, надо тестить)
0
Скажите, а что для реализации Comet вы выбрали (из приведеного по ссылке обзора или чего-то иного)?
0
Похоже сайт всё.
+1
Проект закрыт?
0
Sign up to leave a comment.
Push + ActiveMQ — ZendFramework =… или история одного драйвового проекта