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