К тому же, с балансировкой в реальном времени, мы ведь еще может отдать пользователю самый "близкий" (географически) стрим (если сервис с большим охватом).
Да, они придут на второй нод, а там у нас вообще не продохнуть, потому что оттуда еще не ушли другие пользователи, и они снова ждут. А ноды 27, 44, и 188 вообще курят, потому что так вышло, что никто сейчас на них ничего не смотрит, но как мы туда нагрузку перекинем?
Может мы недопонимаем друг друга. Но Вы предлагаете один файл разбить на 200 частей и 200 раз переключать пользователя на разные стримы. При этом все сервера будут с разной нагрузкой, как можно в таком случае заранее сказать, что на все сервера нагрузка будет распределяться равномерно? Я бы предпочел продублировать один файл на 200 серверов и использовать логику с балансировкой. Просто предзапрос на балансир и вы получаете адрес для стрима, с которого нужно смотреть. Причем если так получилось, что со временем, с 199 серверов пользователи ушли, а 200-м их 100 штук, можно их перекинуть на свободные в процессе. Да балансировщик надо выстроить так, чтобы он быстро обрабатывал запросы, но я бы выбрал такой путь. Скажем так, я по нему уже ходил, может быть в данной ситуации я чего-нибудь недопонимаю.
Т.е. вы хотите сказать, что переключать стрим, бить файлы на куски и следить за всем этим проще чем балансировщик? Мне кажется проще следить за соответствием реплик мастеру, чем бить файлы на куски по какой-то хитрой логике. Опять же, отправляем запрос на балансир, он знает сколько у нас сейчас пользователей к какому стриму подключено, и отдает src для самого свободного.
К слову, о горячих видео, а что Вы будете делать с горячими кусками? Или горячими серверами? Ваша схема просто распределенная, если я все правильно понял, но она статически распределенная. И вообще говоря, не решает проблему распределения нагрузки в реал-тайме.
ИМХО, тогда речь уже о бланасировке нагрузки. Зачем видео то разбивать, есть несколько реплик, и есть баласировщик, который говорит с какого сервера сейчас лучше всего смотреть видео.
Подозреваю, что "разрывы" можно минифицировать. Не обязательно же начинаться загрузку нового куска только тогда, когда первый кончился, можно заранее подгрузить следующий и "спрятать" его до времени. "стриминг-сервером" страшно звучит. Все зависит от первоначальное задачи конечно же. Уверен, что во многих случаях, мой вариант может не прокатить, но мне кажется это самым простым из того, что сразу в голову приходит.
Если речь о Unit тестировании, то в этом случае Вы проверяете, что метод именно свою работу выполняет верно. Т.е. создание запроса к базе, или составление параметров для запроса, это уже выполненная им работа. Чтобы проверить все ли так, вместо настоящего соединения с базой мы подсовываем ему "мок". Причем Unit тесты при изменении архитектуры помогают удостоверится, что не поломалась "не затронутая" часть программы. А вот тесты для измененной функциональности все равно придется менять. Больше или меньше в зависимости от того, какой был масштаб изменения кода приложения.
Что же до "интеграционных" тестов, то я использую их в тех случаях, когда хочу удостоверится, что мой "хитрый запрос" в базе делает именно то, что я придумал. Написание теста занимает немного больше времени, чем просто глянуть в базу, но зато помогает ничего не упустить и держать на контроле именно конечную структуру базы, "оптимизируя" методы работы с базой.
Честно говоря, не совсем понимаю, в чем суть вопроса?
Писать или нет Unit теусты? - зависит от времени и средств выделяемых на проект, тесты повышают качество продукта.
Писать или нет именно тесты на работу с базой? - ответ почти такой же, однако важность Unit тестов на критичные места в приложении (формирование запросов, проверки и преобразование входных данных) я бы поставил выше интеграционных тестов с базой. В конечном итоге: чем проще запросы, тем лучше, и тесты могут не понадобиться, а база и так будет работать как описано в документации, у нее есть свои разработчики и свои тесты.
Да, действительно, и я им довольно долго пользовался. Правда хочу отметить, что его стоит брать отсюда https://github.com/petervanderdoes/gitflow/wiki а не у nvie, так как версия автора давно не поддерживается, а по ссылке выше постоянно развивается и имеет ряд продуманных особенностей. P.S. под винду тоже работает.
Явно об этом в описании методологии не говорится, но мне кажется, что и в расхождение с ней мерж девелопа тоже не идет. Т.е., наверно, в идеальном мире, каждая фича должна выполняться за короткий промежуток времени, явно меньше одной итерации, и в таком мире, периодически мержить девелоп (или ребейсить фичу) не нужно. Но в реальности, на прошлом месте работы, мы использовали git flow, и мерж девелопа в фичу был нормальным явлением. Более того, по хорошему, я обычно делал сначала мерж девелопа в вичу, потом проверял, что ничего ни ломается, или чинил, если поломалось, и только после этого делал мерж фичи в девелоп.
@JekFdrv Скорей похоже на бесплатную помощь ленивым студентам)) Потому как для любого программиста, хоть раз в жизни хотя бы слышавшего про "Регулярные Выражения" решения такой задачи, большой трудности не представляет.
@kompi дело в том, что в данном случае "ни все цифры одинаково полезны")) "Т.е. оставить только ту цифру, которая стоит перед точкой, и убрать запятые"
@nazarpc я конечно же имел в виду только теги вроде и т.п. у которых закрывающий тег существует, но использовать его не обязательно.
В css у меня так же, только я еще делаю отступы для вложенных элементов и для крупных секций использую разделители с комментариями. Разделение свойств на категории слишком субъективно, только усложняет жизнь при командной разработке.
p.s. тоже использую PhpStorm.
@SolidlSnake да вроде ничего особенного. Достаточно на 4-5 уровней вложенной формы с кучкой параметров. А если это twitter bootstrap, так вообще никаких проблем.
А "при следующей отправке" имеется в виду "абсолютный номер следующего запроса на отправление почты" или от одного пользователя? Если в рамках пользователя, можно было бы юзать куки. Если не секрет, зачем вообще такое?
@xmeoff
Беда в том, что до версии 5.4 json_encode шифрует не латинские символы, и если потом этот файлик где-то еще надо читать, будут проблемы. По такому случаю тоже приходилось свой json_encode писать...
