Гонор, тем более на пустом месте, не является ни достоинством ни признаком профессионализма. Если посмотришь на том же фриланс.ру, в каждом проекте толпятся десятки умников, считающих что заказчики должны за ними бегать. Вот мол, моя аська, пишите. Как думаешь, сколько из них получают приличные заказы? Если угораздит учить высшую математику в ВУЗе, вам непременно будут преподавать бесконечно малые величины. Вот это как раз из той области.
Чтобы я/автор/кто-то еще хоть что-то тебе предложил (включая просто принести кофе, не говоря уж о работе) тебе нужно доказать что ты стоишь хотя бы времени, которое будет потрачено на разговор. Сейчас ты демонстрируешь прямо противоположные качества.
Да, и никогда не говори о деньгах «хотя бы» — это дурной тон и для опытного руководителя очень плохой признак. Называй сумму которая тебя полностью устроит либо ничего не говори.
Есть заказчики, есть исполнители. И те и другие не ангелы. Человек описал свой опыт с точки зрения заказчика. Я, исходя из личного опыта, во многом согласен.
В быстность проджект-менеджером я данную задачу решал так:
— четкое ТЗ, в котором задача максимально разбита на подзадачи (максимальная длительность подзадачи — 2 дня)
— план работ, расписаный по дням
— раз в 1-2 дня сквозная сверка, в которой проверяется наличие функционала и бегло просматривается работоспособность.
— раз в неделю функционал полностью тестируется на соответствие тому что должно быть в текущий момент сдано.
Соответственно каждый день все знают что должно происходить и что на самом деле происходит. Не панацея, но косяки/клиника, как правило, выявляются на начальной стадии, не доводя потери сроков/денег до критической массы. Времени тратится на это капитально, но имхо того стоит.
Я в бытность студиозусом успел поработать на Мазовии 1914 (название могу переврать — сколько времени-то прошло). Насколько я помню чудо было 8086, имело на борту 2 5.25 дисковода, мег оперативы. Ну и монитор монохромный чтобы жизнь медом не казалась. Эххх…
1. Спросите хостера ненавязчиво, возможно ли это решить за деньги и сколько бы это стоило.
2. Соберите всю имеющую значение переписку с хостером (включая ответ хостера с ценой)
3. Опишите ситуацию в одном абзаце (чтобы человеку легче было сходу понять ситуацию)
4. Отправьте все это в Руцентр в качестве жалобы на регистратора. Также желательно предварительно позвонить им и посоветоваться что делать в подобной ситуации — куда отправлять, в какой форме, что приложить. Регистратор нарушил правила регистрации доменов (врядли ошибаюсь, хотя конкретный пункт нужно смотреть) и при наличии Вашей жалобы Руцентр может (и должен) надавать регистратору по башке. До взаправдашнего мордобоя дело, конечно, не дойдет (шутка), но вполне возможно что регистратор плюнет на это все и вернет домен «чтобы не связываться».
Я немножко не о том. Построение комму… ютуба в локальной сети провайдера дело хорошее. А то о чем я написал служит исключительно для экономии внешнего траффика, не более того.
Собственно обычная система кэширования, которая регулярно используется многими провайдерами. Разница лишь в селекции кэшируемых файлов (врядли стоит кэшировать все подряд) и выдачу файла пользователю до того как он полностью загружен на кэширующий сервер.
Кстати по свежим размышлениям я бы все же кэшировал все подряд, а селекцию делал на этапе чистки мусора — то что запрашивают оставляем, то что не запрашивают сносим.
Загрузка пользователем видео на видеохостинг будет работать так как и работала.
Кэшировать исходящие пост-запросы (в том числе и отправку файлов) теоретически можно, но на практике очень гемморно, да и врядли нужно — все же пользователи чаще смотрят чем загружают, а вероятность того что два пользователя загрузят абсолютно идентичные ролики, имхо, крайне мала.
К тому же возникает несколько специфических нюансов, которые сводят на нет всю экономию: чтобы проверить файл на идентичность хранимому в кэше нужно полностью его получить. Т.е. мы получаем файл от пользователя, проверяем и отправляем дальше. А сервер-получатель рвет соединение (пользователь не авторизован, файл существует — вариантов вагон). И выходит что мы совершенно зря получали весь файл от пользователя (а региональные провайдеры все еще берут плату за траффик с клиентов, не красиво выходит).
Попросите у заказчика статистику по заргужаемым/получаемым .flv, имхо объем загружаемых будет крайне мал относительно получаемых.
Что еще было бы полезно:
— уведомление по e-mail/sms (второе тяжелее, но было бы просто феерично, не у всех мыло есть)
— в помещении где подают заявки нужно большими буквами написать адрес сайта (плакатик на котором все наглядно расписано) + положить визиточки (хоть на принтере напечатать) на которых это написано — чтобы можно было унести с собой.
— поговорить с телефонистками чтобы они говорили о сайте.
Весь внешний траффик провайдера идет через его же маршрутизатор. Настроить правило на чтобы все запросы на .flv перебрасывались на свою машину труда не составит. Собственно админы провайдера должны сами это уметь без проблем.
А для пользователей вообще никакой разницы — они и не знают откуда идет файл — из внешней сети или с кэширующей машины провайдера.
Имхо для провайдера было бы более правильным сделать кэширование видео основных видеохостингов — дешево и сердито.
Примерно так:
— ставится одна средняя машина с большим винтом, на которую редиректятся все запросы на youtube … .flv
— машина смотрит в свой кэш, если файл есть раздает его.
— если файла нет, но его часто запрашивали за последние сутки, вытягиваем и отдаем. В целях экономии траффика лучше одним потоком тянуть, сохранять к себе и раздавать пользователю. nginx поможет с медленными клиентами.
— если файла нет и не запрашивали, просто редиректим на него и все.
— ну а очистку мусора и проверку изменения файлов сделать не сложно.
Ну и в качестве изюминки можно хранить наиболее часто запрашиваемые ролики в memcahced.
Делается за полдня и решает задачу (экономия внешнего траффика) сразу и надолго.
Аналогично можно расправиться с подкастами и наиболее популярными интернет-радиостанциями.
Имхо самая большая сложность теперь — убедить потенциальных рекламодателей вбухать ощутимые деньги в разработку «квестов» — рекламоноситель новый, эффективность не известна, а порог входа получается весомый.
А вот если бы научиться вылавливать во всех роликах, размещенных на видеохостинге автомобили BMW и делать с них ссылку на сайт диллера, имхо было бы ооочень вкусно — и рекламодателю не нужно вкладываться в ролики и эффективность должна быть на высоте.
Для домашних бэкапов нужнее web-интерфейс внятный + софтинка кроссплатформенная с GUI — немного найдется самураев которые будут ставить Ruby на свою машину чтобы автоматизировать домашний бэкап ))
Смысл в удаленном хранилище возникает когда:
— проблемы с местом на своем сервере/хостинге.
— свой сервер/хостинг не оборудован Raid1/Raid5 и смерть жесткого диска приведет к смерти и бэкапов в том числе.
Частично это можно решить копированием бэкапа на свою локальную машину, но это не всегда возможно/удобно (например когда размер бэкапа переваливает за второй десятко гигов).
Гонор, тем более на пустом месте, не является ни достоинством ни признаком профессионализма. Если посмотришь на том же фриланс.ру, в каждом проекте толпятся десятки умников, считающих что заказчики должны за ними бегать. Вот мол, моя аська, пишите. Как думаешь, сколько из них получают приличные заказы? Если угораздит учить высшую математику в ВУЗе, вам непременно будут преподавать бесконечно малые величины. Вот это как раз из той области.
Чтобы я/автор/кто-то еще хоть что-то тебе предложил (включая просто принести кофе, не говоря уж о работе) тебе нужно доказать что ты стоишь хотя бы времени, которое будет потрачено на разговор. Сейчас ты демонстрируешь прямо противоположные качества.
Да, и никогда не говори о деньгах «хотя бы» — это дурной тон и для опытного руководителя очень плохой признак. Называй сумму которая тебя полностью устроит либо ничего не говори.
Хотя что-то мне подсказывает что не в коня корм.
Успехов.
Почему Вас это так задевает? ))
Без обид.
Не было бы таких частых срывов и не писали бы, имхо.
— четкое ТЗ, в котором задача максимально разбита на подзадачи (максимальная длительность подзадачи — 2 дня)
— план работ, расписаный по дням
— раз в 1-2 дня сквозная сверка, в которой проверяется наличие функционала и бегло просматривается работоспособность.
— раз в неделю функционал полностью тестируется на соответствие тому что должно быть в текущий момент сдано.
Соответственно каждый день все знают что должно происходить и что на самом деле происходит. Не панацея, но косяки/клиника, как правило, выявляются на начальной стадии, не доводя потери сроков/денег до критической массы. Времени тратится на это капитально, но имхо того стоит.
Сработала привычка что хостер=регистратор )
2. Соберите всю имеющую значение переписку с хостером (включая ответ хостера с ценой)
3. Опишите ситуацию в одном абзаце (чтобы человеку легче было сходу понять ситуацию)
4. Отправьте все это в Руцентр в качестве жалобы на регистратора. Также желательно предварительно позвонить им и посоветоваться что делать в подобной ситуации — куда отправлять, в какой форме, что приложить. Регистратор нарушил правила регистрации доменов (врядли ошибаюсь, хотя конкретный пункт нужно смотреть) и при наличии Вашей жалобы Руцентр может (и должен) надавать регистратору по башке. До взаправдашнего мордобоя дело, конечно, не дойдет (шутка), но вполне возможно что регистратор плюнет на это все и вернет домен «чтобы не связываться».
Кстати по свежим размышлениям я бы все же кэшировал все подряд, а селекцию делал на этапе чистки мусора — то что запрашивают оставляем, то что не запрашивают сносим.
Кэшировать исходящие пост-запросы (в том числе и отправку файлов) теоретически можно, но на практике очень гемморно, да и врядли нужно — все же пользователи чаще смотрят чем загружают, а вероятность того что два пользователя загрузят абсолютно идентичные ролики, имхо, крайне мала.
К тому же возникает несколько специфических нюансов, которые сводят на нет всю экономию: чтобы проверить файл на идентичность хранимому в кэше нужно полностью его получить. Т.е. мы получаем файл от пользователя, проверяем и отправляем дальше. А сервер-получатель рвет соединение (пользователь не авторизован, файл существует — вариантов вагон). И выходит что мы совершенно зря получали весь файл от пользователя (а региональные провайдеры все еще берут плату за траффик с клиентов, не красиво выходит).
Попросите у заказчика статистику по заргужаемым/получаемым .flv, имхо объем загружаемых будет крайне мал относительно получаемых.
Что еще было бы полезно:
— уведомление по e-mail/sms (второе тяжелее, но было бы просто феерично, не у всех мыло есть)
— в помещении где подают заявки нужно большими буквами написать адрес сайта (плакатик на котором все наглядно расписано) + положить визиточки (хоть на принтере напечатать) на которых это написано — чтобы можно было унести с собой.
— поговорить с телефонистками чтобы они говорили о сайте.
Весь внешний траффик провайдера идет через его же маршрутизатор. Настроить правило на чтобы все запросы на .flv перебрасывались на свою машину труда не составит. Собственно админы провайдера должны сами это уметь без проблем.
А для пользователей вообще никакой разницы — они и не знают откуда идет файл — из внешней сети или с кэширующей машины провайдера.
Примерно так:
— ставится одна средняя машина с большим винтом, на которую редиректятся все запросы на youtube … .flv
— машина смотрит в свой кэш, если файл есть раздает его.
— если файла нет, но его часто запрашивали за последние сутки, вытягиваем и отдаем. В целях экономии траффика лучше одним потоком тянуть, сохранять к себе и раздавать пользователю. nginx поможет с медленными клиентами.
— если файла нет и не запрашивали, просто редиректим на него и все.
— ну а очистку мусора и проверку изменения файлов сделать не сложно.
Ну и в качестве изюминки можно хранить наиболее часто запрашиваемые ролики в memcahced.
Делается за полдня и решает задачу (экономия внешнего траффика) сразу и надолго.
Аналогично можно расправиться с подкастами и наиболее популярными интернет-радиостанциями.
А вот если бы научиться вылавливать во всех роликах, размещенных на видеохостинге автомобили BMW и делать с них ссылку на сайт диллера, имхо было бы ооочень вкусно — и рекламодателю не нужно вкладываться в ролики и эффективность должна быть на высоте.
А в общем и целом весьма вкусно ))
— проблемы с местом на своем сервере/хостинге.
— свой сервер/хостинг не оборудован Raid1/Raid5 и смерть жесткого диска приведет к смерти и бэкапов в том числе.
Частично это можно решить копированием бэкапа на свою локальную машину, но это не всегда возможно/удобно (например когда размер бэкапа переваливает за второй десятко гигов).