Я полагаю суть вопроса не в том как не нанести ущерб, а том что за это будет. Как бы вы не работали вам может попасться неадекватный заказчик который начнёт вас обвинять в тех багах которые могли быт созданы до вас. Особенно будет тяжело доказать вашу невиновность если баг начнёт проявляться только после ваших правок.
На пример я видел плагин личных сообщений к modx который ложил весь сайт после того как в бд накопится больше 5000 сообщений. Просто потому что запросы к бд были кривые. Вот такие ситуации вы на тестовом сервере не обнаружите, да как бы и не должны обнаружить особенно если ваши правки не затрагивают этот функционал.
Stalinko, А можете поделится ссылкой на ваш профиль. Очень интересно как он выглядит. Я когда пробовал получить хоть какую то пользу от LinkedIn так и не понял как он работает.
Хотел вступить в несколько сообществ так там поиск совсем не работал, он дал небольшой список сообществ на основе тех навыков какие я в профиле задал и всё, я так и не понял как можно найти хоть что то полезное или интересное в LinkedIn.
Я с коллегами изучал гитхаб проекты кандидатов. Это эффективнее чем звать на собеседование непонятно кого. Мы собеседовали втроём. И каждое собеседование обходилось минимум в 3 человека часа для нашей компании.
Посмотреть github проект можно гораздо быстрее. И уже становится ясно многое.
Антон Тихомиров, Возможно там было на флеше сделано. В rtmp задержка меньше чем в hls или mpeg-dash. В hls я полагаю 6 секунд минимум. Но допускаю что можно что то выдумать и сократить до 4 секунд. Но не до 0.3 как это при работе с rtsp.
Антон Тихомиров, hls_fragment влияет и dash_fragment это длина фрагмента чем меньше тем меньше теоритически возможная задержка.
Но плеер воспроизводил стрим не с конца списка файлов а с начала. Таким образом на задержку влияло ещё dash_playlist_length и hls_playlist_length я пробовал ставить 3 тогда задержка получалась около 16 секунд если ставить 2 то начинало нестабильно работать так как nginx удаляет файлы которые вышли за пределы листа.
А вот если на клиенте искуственно укорачивать список воспроизведения до 2 последних фрагментов то влияние параметров playlist_length устраняется и в таком варианте оно работает.
Мне низкая задержка нужна так как я делаю вебинары с контентом 18+ и там "ведущему" пишут в чат люди и они не готовы ждать долго чтоб увидеть на видео реакцию на их сообщение.
marataziat, Ну как бы вот теперь ещё и это есть. Для меня это хобби + источник клиентов на фрилансе. И в отличии от других SaaS сервисов есть ещё и опенсорс версия. Так что это тот редкий случай когда у вас нет вендер лока при использовании апи SaaS сервиса. И есть возможность развернуть всё у себя не переписывая код приложения.
Виктор, Некоторые клиенты при подключении запрашивают кучу справочной информации, помимо непосредственно подключения. Не все типы запросов мой парсер способен обработать так как я не поддерживаю граматику sql в полной мере. Поэтому GUI клиенты могут не работать даже если подключение установилось нормально.
Эдуард, C yii я лично не знаком и не знаю как там делать несколько коннектов к разным бд. Но помимо моего комет сервера есть ещё sphinx search в нём тоже используется SphinxQL (Я этим проектом и вдохновлялся) и полагаю под многие фраимворки есть какие то решения работы с несколькими коннектами по протоколу mysql
Эдуард, Да уже давненько живёт. И мене этот проект хороших заказчиков приносит так что поддерживать его я планирую ещё достаточно долго. Хотя согласен с тем что пока проект не обрёл большой популярности фактор автобуса не очень то велик по сравнению с аналогичными решениями.
Но все исходники в опенсорсе. Так что если кому то будет очень надо смогут развивать дальше.
Пума Тайланд, Я считаю себя хорошим специалистом, но сижу на тостере так как считаю раздел "Интересные вопросы" и вопросы по интересным для меня тегам ценным источником информации.
Ну и свой проект тоже продвигаю отвечая на некоторые из вопросов.
Alexander Morozov, по моему опыту мне кажется что любую работу с отправкой данных в вебсокеты можно поделить на код работающий с вебсокетами и на бизнес логику приложения.
Если я прав в этом предположении то получается как бы вы не писали с нуля или на библиотеках у вас получится комет сервер и бизнес логика. И эти 2 компонента будут взаимодействовать между собой. Либо через апи либо будут слеплены в единый комок кода.
Только переносить наработки из проекта в проект гораздо удобнее если у вас нормальная архитектура и бизнес логика отделена от вспомогательного кода.
Вот и получится что если вы делаете более одного приложения то рано или поздно в результате переиспользования своего же кода у вас будет отдельно комет сервер и отдельно код приложения. Так что рационально взять готовый комет сервер а не писать его с нуля.
S Zh, порой дольше переделывать чем сразу нормально сделать. Тем более что порог входа для работы с веб сокетами очень небольшой. Уже нет необходимосити вникать в работу протокола и прочее. Достаточно просто вовремя вызвать апи вебсокет сервера.
На пример я видел плагин личных сообщений к modx который ложил весь сайт после того как в бд накопится больше 5000 сообщений. Просто потому что запросы к бд были кривые. Вот такие ситуации вы на тестовом сервере не обнаружите, да как бы и не должны обнаружить особенно если ваши правки не затрагивают этот функционал.