По порядку.
У моего партнера была определенная «подогретая» аудитория + какое-то кол-во информационных партнеров. Также информацию выставляли у себя в соц. сетях преподаватели.
Школы у моего партнера находятся в России, а доля РФ трафика составила около 25%.
Учитывая разные погрешности и т.п., можно предполагать что около 70% аудитории не посещали его школы никогда.
После окончания пандемии и карантинов ясное дело, что откроются оффлайн лагеря. Однако стоит принять во внимание тот момент, что далеко не все ученики\танцоры могут позволить себе регулярно ездить в Европу или США или Азию на подобные лагеря. Я не смогу назвать точных цен, но условно онлайн участие будет стоить от 10 до 20% стоимости оффлайн лагеря + расходы на перелет. К тому же, состав преподавателей в онлайне может быть абсолютно любой, в оффлайне тут уже накладываются свои факторы и трудности.
Добрый день. Нам надо было отзеркалить картинку.
Такое требование было заложено. Это нужно для корректной подачи информации преподавателем.
Приложений, которые отдают отзеркаленную картинку мы не нашли =(
CDN тоже не зеркалит.
Поэтому у нас была маленькая виртуалка с nginx + rtmp для этого.
Если бы этого требования не было — стримили напрямую бы конечно же =)
общая связка такая
1) у преподавателя стоит larix broadcaster
приложение которое умеет стримить rtmp
2) этот поток идет на наш «рестриминговый» сервер
там мы зеркалим картинку, и отправляем в cdn
видим статистику по входящему потоку
3) cdn отдает нам hls плейлист
4) на клиенте стоит videojs
Назвать реальные суммы не могу. На текущий момент затраты составляют 60%.
При дальнейшем масштабировании они снизятся до 25-30% (здесь я имею ввиду затраты на cdn, оплата преподавателей, налоги, комиссии). Снижение идет за счет наличия гибкой системы оплаты во многих расходных статьях.
Как я писал выше — была уже определенная «подогретая» аудитория.
Маркетинг был в соц. сетях. К нему были также подключены преподаватели и информационные партнеры. Условно — продукт проверялся на неком сформированном сообществе.
Около 5% людей оставляют фидбэк после лагеря. Мы его изучаем и видим, что потребность в продукте есть. Потребность основана на том, что многие люди действительно не могут переместиться в Европу на подобные мероприятия.
На текущий момент мы думаем о том, как расширить продукт и его аудиторию.
Буду рад совету в ЛС. Там же могу более предметно ответить на вопросы о $
Порядок цифр вы сможете найти в РБК, если возьмете фитнес сферу.
Убытки +- сопоставимы.
Ну в любом случае люди делают проекты для того, чтобы заработать. Это логично.
Но в данном кейсе проект сможет существовать и дольше. И после карантина.
Т.к. не у всех людей есть возможность поприсутствовать на оффлайн мероприятии.
Полная аналогия с IT мероприятиями. Там же есть такой формат =)
Перевод деятельности в онлайн дело не малое. И это не колбасу продавать.
Это техника + софт + менеджмент. Если кажется что просто — можете попробовать сами и после этого написать о своих успехах.
Детали, которые я посчитал нужным — я описал в статье.
Кому то они будут полезны. Многое из того, что я описал — я не находил на сторонних ресурсах. Это условный список нюансов, к чему надо быть готовым.
Мы с этого (я и мой партнёр) заработали. Танцоры тоже.
В минус мы не ушли :)
Пояснять финансовую сторону думаю здесь никто не будет. Не налоговая.
И ещё раз — организация онлайн кэмпа и перевод в видео это немного разные вещи.
Я соглашусь, что оба варианта красивые =)
Просто вне этого стартапа, на основном месте работы нагрузки выше, поэтому и активно его (свое решение) пропагандирую :)
В любом случае я уже стал щупать симфони 5, за что Вам спасибо!)
Тогда не совсем понимаю зачем эти действия.
Я вам предложил купить УАЗик, чтобы лазить в грязь и поле.
На первое время пока на гелик не накопили.
Если что — его можно продать потом таким же фанатикам.
Вы мне предлагаете купить бентли, и надеть на него сначала подвеску повыше, потом резину, потом задний мост и т.п. Потом вы бросите его, уйдете из конторы. Придет другой разработчик, будет на это смотреть и диву даваться.
В моем решении мы имеем
1) простую очередь (замечу, что ее можно использовать не только для рассылок)
2) изолированный микросервис для рассылок (легковесный, 8мб в докере)
3) используем go либу для амазона, и пишем GET/POST запрос для отправки СМС куда душе угодно
У вас же 2 библиотеки минимум + та же самая очередь потребуется (для асинхронной рассылки) + также надо имплементацию писать.
А если завтра надо 500.000 писем отсылать?
И 50.000 смс, и полтора миллиона пушей?
При этом у вас еще есть лимиты на отсылку по аккаунту в минуту и день. И в дневной вы пока не убираетесь.
Тогда вы чуть правите микросервис — добавляете рейт лимитер (стандартный пакет в go вроде есть) и поддерживаете еще 1 аккаунт и равномерно рассылаете например с 2х.
А PHP часть при этом неизменна. Да и если мы достигнем лимитов — очередь не теряет данные.
В вашем же кейсе возникают вопросы — как прикрутить 2 аккаунта, как добавить рейт лимитер. Как прикрутить рейт лимитер к рассыльщику и т.п.
Так ваш проект начнет уже на старте обрастать тех долгом, костылями.
Решение из коробки это классно, но только если вы на 100% уверены что не придется его масштабировать. Как например HWIOAuthBundle. Есть он и есть. Ничего с ним делать не надо
Как я писал выше, мой партнер владеет сетью танцевальных школ.
У него есть своя аудитория. Также информацию о лагерях распространяли преподаватели и партнеры проекта.
Мы достигли успеха за счет того, что
1) были потребители (и рынок)
2) была гипотеза, что нужно этой аудитории в карантин
3) появился я, кто смог за 2 недели быстро «окучить» эту аудиторию и сделать MVP
p.s.
ну и этот «сторонний сервис» может элементарно отвалиться.
тогда очередь будет хранить сообщения, а в момент перезапуска сервиса — события выполнятся (письма уйдут получателям)
Добрый вечер.
Судя по негативу вашего сообщения, вы видимо как раз работаете на этом колбасном заводе кодером на пол-ставки, и пилите онлайн-магазин.
Если верить Стивену Бланку, то стартап, это не что иное, как временная структура, существующая для поиска воспроизводимой и масштабируемой бизнес-модели.
Мы как раз ищем такую.
Мы провели 2 лагеря — т.е. модель воспроизводима.
А вот масштабируемость сложно проверить в условиях пандемии.
Про выводы — мы с товарищем инвестировали вместо денег свое собственное время. Я был «кодером», а он «маркетологом». Я очень сомневаюсь что топовые танцоры по первому вашему приглашению сами организуют и проведут все.
Я в посте расписывал технические нюансы, проблемы с биллингом и т.п.
Я не писал о том, откуда эта аудитория, откуда эти танцоры, почему они согласились — а это тоже большой труд и временные инвестиции моего партнера.
Стартап — это не всегда инновации. При создании стартапа бизнесмены пытаются при помощи своего продукта решить проблему людей. Именно это мы и делали в условиях пандемии.
И это у нас отлично получилось, судя по фидбэку от конечных пользователей
Добрый вечер.
Зрители были со всего мира. Преподаватели делятся уже по странам света.
Мы провели уже 2 лагеря.
В первом были преподаватели из Европы (и как вы верно подметили, РФ тоже Европа, поэтому Российские преподаватели были тоже).
Второй лагерь был собран из преподавателей из США.
По поводу аудитории —
25% Российский трафик, 75% — остальной
Добрый вечер. Спасибо за ответ =)
Позволю дополнить от себя.
Можно заменить «не ждать ответа SMTP сервера» на «не ждать ответа от стороннего сервиса рассылок».
В общем случае там может быть что угодно, smtp, amazon api, и т.п.
«современный пользователь не хочешь ждать» — в точку! =)
на этом и акцент
Добрый вечер. Спасибо за отзыв. Comet не пробовал, EasyAdminBundle тоже.
Глянув одним глазком EasyAdminBundle, думаю надо пробовать в следующем проекте =)
Красивый вроде как)
По поводу Go — мне на нем очень нравится писать маленькие микросервисы. Но на самом деле каждому свое. И фломастеры на вкус все разные =)
Но у меня уже есть набор готовых типа sms, email, webhook, e.t.c.
Которые я могу применять в различных новых проектах.
(2 недели как раз отсюда, многие решения модульные и просто копируются ;)
По поводу очереди — эта вещь удобна не только в плане рассылок.
Как я и писал — ее очень легко поднять в докере, и также легко отказаться от нее.
Идея методики что я описал в гибкости. Чтобы манипулируя лишь переменными среды настраивать связки. Будь то PHP -> SMTP, или же PHP -> Dummy, или PHP -> RABBIT -> GO -> Amazon
По порядку.
У моего партнера была определенная «подогретая» аудитория + какое-то кол-во информационных партнеров. Также информацию выставляли у себя в соц. сетях преподаватели.
Школы у моего партнера находятся в России, а доля РФ трафика составила около 25%.
Учитывая разные погрешности и т.п., можно предполагать что около 70% аудитории не посещали его школы никогда.
После окончания пандемии и карантинов ясное дело, что откроются оффлайн лагеря. Однако стоит принять во внимание тот момент, что далеко не все ученики\танцоры могут позволить себе регулярно ездить в Европу или США или Азию на подобные лагеря. Я не смогу назвать точных цен, но условно онлайн участие будет стоить от 10 до 20% стоимости оффлайн лагеря + расходы на перелет. К тому же, состав преподавателей в онлайне может быть абсолютно любой, в оффлайне тут уже накладываются свои факторы и трудности.
Такое требование было заложено. Это нужно для корректной подачи информации преподавателем.
Приложений, которые отдают отзеркаленную картинку мы не нашли =(
CDN тоже не зеркалит.
Поэтому у нас была маленькая виртуалка с nginx + rtmp для этого.
Если бы этого требования не было — стримили напрямую бы конечно же =)
1) у преподавателя стоит larix broadcaster
приложение которое умеет стримить rtmp
2) этот поток идет на наш «рестриминговый» сервер
там мы зеркалим картинку, и отправляем в cdn
видим статистику по входящему потоку
3) cdn отдает нам hls плейлист
4) на клиенте стоит videojs
(что внутри cdn подсказать не могу)
Назвать реальные суммы не могу. На текущий момент затраты составляют 60%.
При дальнейшем масштабировании они снизятся до 25-30% (здесь я имею ввиду затраты на cdn, оплата преподавателей, налоги, комиссии). Снижение идет за счет наличия гибкой системы оплаты во многих расходных статьях.
Как я писал выше — была уже определенная «подогретая» аудитория.
Маркетинг был в соц. сетях. К нему были также подключены преподаватели и информационные партнеры. Условно — продукт проверялся на неком сформированном сообществе.
Около 5% людей оставляют фидбэк после лагеря. Мы его изучаем и видим, что потребность в продукте есть. Потребность основана на том, что многие люди действительно не могут переместиться в Европу на подобные мероприятия.
На текущий момент мы думаем о том, как расширить продукт и его аудиторию.
Буду рад совету в ЛС. Там же могу более предметно ответить на вопросы о $
Убытки +- сопоставимы.
Ну в любом случае люди делают проекты для того, чтобы заработать. Это логично.
Но в данном кейсе проект сможет существовать и дольше. И после карантина.
Т.к. не у всех людей есть возможность поприсутствовать на оффлайн мероприятии.
Полная аналогия с IT мероприятиями. Там же есть такой формат =)
Это техника + софт + менеджмент. Если кажется что просто — можете попробовать сами и после этого написать о своих успехах.
Детали, которые я посчитал нужным — я описал в статье.
Кому то они будут полезны. Многое из того, что я описал — я не находил на сторонних ресурсах. Это условный список нюансов, к чему надо быть готовым.
Мы с этого (я и мой партнёр) заработали. Танцоры тоже.
В минус мы не ушли :)
Пояснять финансовую сторону думаю здесь никто не будет. Не налоговая.
И ещё раз — организация онлайн кэмпа и перевод в видео это немного разные вещи.
Просто вне этого стартапа, на основном месте работы нагрузки выше, поэтому и активно его (свое решение) пропагандирую :)
В любом случае я уже стал щупать симфони 5, за что Вам спасибо!)
Я вам предложил купить УАЗик, чтобы лазить в грязь и поле.
На первое время пока на гелик не накопили.
Если что — его можно продать потом таким же фанатикам.
Вы мне предлагаете купить бентли, и надеть на него сначала подвеску повыше, потом резину, потом задний мост и т.п. Потом вы бросите его, уйдете из конторы. Придет другой разработчик, будет на это смотреть и диву даваться.
В моем решении мы имеем
1) простую очередь (замечу, что ее можно использовать не только для рассылок)
2) изолированный микросервис для рассылок (легковесный, 8мб в докере)
3) используем go либу для амазона, и пишем GET/POST запрос для отправки СМС куда душе угодно
У вас же 2 библиотеки минимум + та же самая очередь потребуется (для асинхронной рассылки) + также надо имплементацию писать.
А если завтра надо 500.000 писем отсылать?
И 50.000 смс, и полтора миллиона пушей?
При этом у вас еще есть лимиты на отсылку по аккаунту в минуту и день. И в дневной вы пока не убираетесь.
Тогда вы чуть правите микросервис — добавляете рейт лимитер (стандартный пакет в go вроде есть) и поддерживаете еще 1 аккаунт и равномерно рассылаете например с 2х.
А PHP часть при этом неизменна. Да и если мы достигнем лимитов — очередь не теряет данные.
В вашем же кейсе возникают вопросы — как прикрутить 2 аккаунта, как добавить рейт лимитер. Как прикрутить рейт лимитер к рассыльщику и т.п.
Так ваш проект начнет уже на старте обрастать тех долгом, костылями.
Решение из коробки это классно, но только если вы на 100% уверены что не придется его масштабировать. Как например HWIOAuthBundle. Есть он и есть. Ничего с ним делать не надо
Стримили на него.
Зеркалили картину и отправляли по RTMP дальше в CDN.
Если бы не «зеркало», напрямую RTMP слали бы в CDN.
Про флеш увы ничего не могу сказать
в контексте сервера
входной поток мы отправляем сюда — push rtmp://localhost/cdn;
а внутри этого потока уже мы зеркало делаем, и отправляем в cdn
exec ffmpeg -i rtmp://localhost/cdn/$name -vf «hflip» -crf 30 -preset ultrafast -acodec aac -strict experimental -ar 44100 -ac 2 -b:a 128k -vcodec libx264 -x264-params keyint=60:no-scenecut=1 -r 30 -b:v 2000k -f flv rtmp://rtmp.cdnhost.abc;
rtmp.cdnhost.abc — это рыба.
для получения адреса вам стоит завести аккаунт в cdn
Да, помню время раньше пользовался ими тоже =)
Но учтите, что вам придется пройти модерацию в Amazon SES
Как я писал выше, мой партнер владеет сетью танцевальных школ.
У него есть своя аудитория. Также информацию о лагерях распространяли преподаватели и партнеры проекта.
Мы достигли успеха за счет того, что
1) были потребители (и рынок)
2) была гипотеза, что нужно этой аудитории в карантин
3) появился я, кто смог за 2 недели быстро «окучить» эту аудиторию и сделать MVP
ну и этот «сторонний сервис» может элементарно отвалиться.
тогда очередь будет хранить сообщения, а в момент перезапуска сервиса — события выполнятся (письма уйдут получателям)
Судя по негативу вашего сообщения, вы видимо как раз работаете на этом колбасном заводе кодером на пол-ставки, и пилите онлайн-магазин.
Если верить Стивену Бланку, то стартап, это не что иное, как временная структура, существующая для поиска воспроизводимой и масштабируемой бизнес-модели.
Мы как раз ищем такую.
Мы провели 2 лагеря — т.е. модель воспроизводима.
А вот масштабируемость сложно проверить в условиях пандемии.
Про выводы — мы с товарищем инвестировали вместо денег свое собственное время. Я был «кодером», а он «маркетологом». Я очень сомневаюсь что топовые танцоры по первому вашему приглашению сами организуют и проведут все.
Я в посте расписывал технические нюансы, проблемы с биллингом и т.п.
Я не писал о том, откуда эта аудитория, откуда эти танцоры, почему они согласились — а это тоже большой труд и временные инвестиции моего партнера.
Стартап — это не всегда инновации. При создании стартапа бизнесмены пытаются при помощи своего продукта решить проблему людей. Именно это мы и делали в условиях пандемии.
И это у нас отлично получилось, судя по фидбэку от конечных пользователей
Последний преподаватель был Brian Puspos.
Погуглив его имя в сети, возможно найдете ответ на свой вопрос.
По поводу стриминга — у нас и не было цели свой стриминг делать.
Наша цель была занять танцевальное сообщество, которое «грустило» в карантин =)
Зрители были со всего мира. Преподаватели делятся уже по странам света.
Мы провели уже 2 лагеря.
В первом были преподаватели из Европы (и как вы верно подметили, РФ тоже Европа, поэтому Российские преподаватели были тоже).
Второй лагерь был собран из преподавателей из США.
По поводу аудитории —
25% Российский трафик, 75% — остальной
Позволю дополнить от себя.
Можно заменить «не ждать ответа SMTP сервера» на «не ждать ответа от стороннего сервиса рассылок».
В общем случае там может быть что угодно, smtp, amazon api, и т.п.
«современный пользователь не хочешь ждать» — в точку! =)
на этом и акцент
Глянув одним глазком EasyAdminBundle, думаю надо пробовать в следующем проекте =)
Красивый вроде как)
По поводу Go — мне на нем очень нравится писать маленькие микросервисы. Но на самом деле каждому свое. И фломастеры на вкус все разные =)
Но у меня уже есть набор готовых типа sms, email, webhook, e.t.c.
Которые я могу применять в различных новых проектах.
(2 недели как раз отсюда, многие решения модульные и просто копируются ;)
По поводу очереди — эта вещь удобна не только в плане рассылок.
Как я и писал — ее очень легко поднять в докере, и также легко отказаться от нее.
Идея методики что я описал в гибкости. Чтобы манипулируя лишь переменными среды настраивать связки. Будь то PHP -> SMTP, или же PHP -> Dummy, или PHP -> RABBIT -> GO -> Amazon