|
2 Репликант
И что? Еще раз: где здесь именно необходимо искусство? [кусь...]
Там давно уже опробовано и местами используется WebTV, но то КАК оно используется поражает своим скудоумием. Сумашедший по вычислительной мощности проц (вру, в существующих системах используют 2 проца! - какая расточительность) на стороне клиентской приставки используется лишь для декодирования MPEG4, и web-серфинга, эка невидаль. И эти коробки имеют ПРИЛИЧНОЕ НЕДЕШЕВОЕ ПЗУ на немалое количество мег, в то время как в прототипе нашей системы, ядро OS грузиться при включении "погремухи" в сеть на этих сумашедших скоростях примерно за 2 сек (у нас полоса - 10mbit от клиента до ближайшего разветвителя - дальше - любая требуемая). Точно так же и с другим ПО (прошу обратить внимание на идею проката ПО, высказанную ранее). Вот вам и первая идея (правда c приличной бородой), но почему-то не реализованная в подобных продуктах на рынке. (стоит остановиться и попытаться представить, что это дает - у нас на стороне клиента мощнейшая коробка, практически компьютер, в котором сидит только тупой минимальный загрузчик слегка обремененный некоторым шифрованием, качаем туда - что душе угодно)Почему такого до сих пор нет? Да именно потому что для данной схемы нужна именно ЦЕЛЬНАЯ система, начиная с серверов провайдера, проходя через инфраструктуру сети и заканчивая клиентской погремухой. Все должно работать заведомо согласовано. Для того, чтобы подобная система стала реальностью, необходимо совместить интересы провайдера и производителя подобной аппаратуры (IBM, Philips и еще куча фирм балуются подобными игрушками; правда, успешно не продается практически ничего, оно просто ЕСТЬ)
Тендер-то он ведь небось не проводил или ваше решение стоит меньше 10 тыс.$$?
Ну, скажем, слегка ошиблись, примерно на порядок. Но, в любом случае, это на порядок дешевле получается, чем разработка на западе.
Вы хотите сказать, что область, к-рой вы занимаетесь новая или передовая? Отнюдь! Это точно. Возможно ваше решение будет значительно дешевле и при этом будет удовлетворять заказчика.
Именно. Заказчик - немаленький провайдер кабельного телевидения. Эти устройства ставятся в квартиры клиентов за счет поставщика услуг. От цены зависит - быть вообще проекту, или не быть в блишайшие 3-5 лет, ибо разница в стоимости в 4 раза - это много. (имеется ввиду стоимость единицы "коробки", как она в конечном итоге обойдется заказчику). За те деньги, которые провайдет может "бескорыстно" выделить на переделку инфраструктуры, никто из серьезных фирм даже разговаривать не будет. Заказчику, в принципе, все равно, он от этого прибыль не получит, (пока, по крайней мере). А к тому моменту, когда именно это начнет приносить дополнительный доход, сверх основного (дай бог, чтобы через 5 лет), все уже может быть совсем по-другому. Но ситуация такова, что существующие программные наработки в области видео (бесплатные - DivX и платные - MPEG4), в области операционных систем (даже платные из разряда RTOS стоят в последние годы смехотворно) и возможности и цена аппаратуры (тот Alchemy - вполне самодостаточный контроллер на 600Мгц за $35) позволяют вполне реально сделать это УЖЕ СЕЙЧАС. Более того, это было реально даже год назад (правда аналогичные процы чуть дороже стоили :) )
В период 1997-1999 гг. я занимался проектами, посвященными IP-телефонии (IPT, VoIP и прочии технологии). [кусь...]
К счастью, физически сетка будет у провайдера своя, взамен существующей аналоговой, так что добиться адекватной пропускной способности нам будет легче, нам предоставляется счастливая возможность разработать сетку с "чистого листа" (уже одно это немного поднимает настроение :) )
НО учтите, что имеется развитие рынка этих решений, за к-рым необходимо следить и заказчик тоже может следить. Так что это не рынок заказных ИС/ПО, к-рый еще очень не скоро насытится.
Правда ваша - этот рынок близок к насыщению, и устоявшиеся стандарты и решения - тому подтверждение. Изобретать велосипед никто не собирается. Полно готовых к использованию алгоритмов кодеков, протоколов
Заплатив за плату с таким крутым кодеком (10-20 тыс.$$) можно было передавать видео чутьли не в формате QCIF (20-30 fps) или даже DQCIF (5-10 fps) через канал в 64 кбит/с при цвете RGB 3:2:2 или что-то там такое, т.е достаточно приличная цветопередача.
:)) интересные были времена...
У нас требование - полнокачественный NTSC для начала, с возможностью потом постепенно перебраться на HTV (в течении 2 лет).
Поняв, что стену не прошибить начали искать российских Кулибиных и Самоделкиных. Да, нашли и много! Каких только нам кодеков не предлагали.
Повторюсь, немного не тот случай.
Мне это желание хорошо знакомо, когда все хочется самому - "покорить Эльбрус" в 1001-й раз. От этого желания надо избавляться. Темы эта очень и очень не нова - DCTV, MMTV и прочие конвергентные IP-технологии. Что вы думаете по этому поводу?
Нужен конкретный продукт, с МАКИМУМ изначально заложенных потенциальных возможностей. (кабельщики - народ тяжелый на переделки, да оно и понятно) Именно такая постановка вопроса и греет душу. Никто не требует в первой же реализации всего наворота, достаточно будет уверенного просмотра TV и мелких фишечек, типа кадр-в-кадре и т.д. Но вопрос стоит так, что выбранный подход к реализации системы ТОЖЕ ЭТОГО НЕ ТРЕБУЕТ. Коиентам всегда будет доступна самая последняя версия ПО и, соответственно, самый полный набор услуг. Не сомневаюсь, что на некоторой стадии работы будет подключено масса народа, но пока (согласись) 2-м энергичным спецам, покрывающим предметную область это вполне по-силам. Самое ценное в этой ситуации то, что мы с моим товарищем имеем опыт разработки подобных проектов с 0-ля вплоть до подготовки материалов для серийного производства.
... Границ для фантазии нет. Концепция и реализация полностью в нашем ведении.
Эта фраза подозрительна сама по себе. Вы еще выполняли роль и маркетолога(ов) для заказчика? Поскольку делаются какие-то предварительные выводы о потребностях будущих пользователей - "Концепция ... полностью в нашем ведении" или имелось в виду что-то другое?
Надеюсь, с учетом вышесказанного уже не кажется такой подозрительной. И что за манера, постоянно опираться на "требования" или "потребности" будущих пользователей? Нет этой потребности! Ее надо еще только создать. Поэтому, максимум изначально заложенных возможностей - неплохая база для создания этих самых потребностей. Одно дело писать системы на заказ, другое дело создавать продукт, для которого требования не и звестны, а ВЫДУМЫВАЮТСЯ. (Разве были известны все требования к Win1.0 и старше? Нет, их искуственно создали, а потом уже появилась потребность)
Термин "потребность", может применяться тогда, когда есть аналоги и заведомо известно, что некоторая возможность возможна (каламбур). У меня есть потребность слетать на Луну - смешно! Однако, если бы это было обычным делом, то моя потребность - уже рынок.
Вот-вот и у нас те же проблемы были. Это сегодня нереальные? Может быть, если вы рынок исследовали. А через полгода? Есть хоть какие-то грубые прогнозы или вы абсолютно уверены, что уже закончите проект в срок
По-идее, проект не закончиться никогда, область специфическая. А те самые минимальные результаты, от которых можно потом плясать, вполне достижимы.
IMO у вас же в корне неправильный или какой-то однобокий подход в проектировании - вы получаете и используете только статическую модель архитектуры. Чтобы понять ЧТО делает ваша система необходимо читать варианты использования, а чтобы понять КАК она это делает - читать исходные тексты на С++
Может у меня просто с головой немного непорядок, но я еще никогда не задавался целью понять что и как делают разработанные мною системы. Я это в любой момент ЗНАЮ с произвольными подробностями. И исходные текты я не читаю, я их пишу. :) (чукча писатель, однако). Я могу еще иногда названия классов или файлов читать, но исходники - практически никогда, если я их писал, то кто лучше меня знает - что там?
Мне кажется, что мы давно уже поняли друг друга, просто у каждого в жизни был именно свой профессиональный опыт.
Вы вот неявно сетуете на ИТ-науку. А она ведь не может быть неправильной, т.к ее выводы/результаты доказаны и апробированны множеством проектов.
Боже меня упаси сетовать на науку! Ее исренне люблю и уважаю. Сетуют обычно на конкретных людей. Я частенько сетую на "узколобых" специалистов. Принципиально грамотный человек не может быть узкоспециализированным. Одна область никак не в состоянии утолить "аппетит".
Извините, но IMHO в вас говорит отсутствие определенного образования. Можно предположить, что вам не хватает знаний в области инженерии ПО и ИТ-менеджмента. Так зачем пытаться судить? Подобные суждения чем-то напоминают высказывания типа "MSF круче всех" или "Windows - ацтой". Пожалуйста, не уподобляйтесь. Ваш проект мог провалиться из-за десятка причин. Я сразу могу предположить две - неумелое руководство и организация проекта или вообще их полное отсутствие и непрофессионализм нек-рых участников :о(
Как раз, когда он стал "наш", он довольно быстро благополучно завершился.
Если учесть, что мне на тот момент был 21 год, а моему товарищу 24, то в плане ИТ-менеджмента уж точно не хватало образования. Его тогда у нас просто не существовало. Этим понятиям У НАС от силы лет 5-6. Образования вообще никогда не хватает. Институтская программа просто смехотворна. Изучил примерно в 5 раз больше материала чем требовалось во время учебы в ВУЗе, - и все равно образования не хватает! :) А сейчас дурацкая необходимость все-время работать просто развивает во мне панический страх, что я где-то "не успею", за своей родной, но такой непостоянной IT областью. :)
7 - только для одного. Почему? Потому что я могу судить по своим хорошим знакомым, к-рые работают в одной московской конторе, к-рая занимается цифро-аналоговыми устройствами. Правда, их основнй профиль - это цифровые устройства на базе процессоров Atmel, Risc-процессоров Intel, Hitachi, смарткарты, флэшнакопители высокой емкости, заказные сети на базе RS-422, FireWire и т.п.
Твои друзья - обычные цифровики. Заставь их разработать TV или ВЧ-тракт с заданным отношением сигнал/шум, и стразу станет понятно, что на п.7 одного человека ну никак не достатотчно. Как раз схема цифровой части за мной. Но как раз там - наименьший простор для фантазий. Все будет решать цена комплектующих при ДОСТАТОЧНОЙ функциональности (где-то я подобное уже слышал, причем не от себя :) )
Также следует учитывать, что, как правило, мало специалистов только по аналоговым или только по цифровыми сигналам и их обработке. Таковыми являются достаточно узкие специалисты, например, по hi-end звукотехнике (колонки/динамики) или спутниковому ТВ (декодеры).
О чем и речь. О таких спецах как он я даже и не слышал. А ведь у нас в Севастополе целая "школа" была, все-таки производство военной электроники (в этом мы НИКОГДА от них не отставали)...
Ваши пункты 1-8 меня просто "слегка" смущают.
Чем это они смущают? Эти пункты не даны "сверху". Все, что дано сверху я изложил в одном предложении в предыдущем посте на эту тему. Предложи свои.
Возхможны 2 выбора: либо большая команда узких специалистов, либо маленькая команда универсалов. Но алгоритм тот же самый потому что он определяет грамотный (инженерный) подход .
Мне нравится слово "системный" подход. Из всех материалов, прочитаных в форумах на эту тему сделал для себя вывод, что всю жизнь использовал более, чем грамотный подход, правда с оговорками:
1. Форматы документов обычно оговаривались в конце. Но это еще никогда не вызывало затруднений, вордом, слава богу, владеем.
2. В процессе разработки зачастую использовался обычные структурированные документы ворда, куда "накидывался" материал, диагаммы и прочая ерунда. Правда, подобного рода "документация" довольно четко классифицировалась и соответственно структурно хранилась (в каталогах), а так же всегда существовал "путеводитель" по имеющимся нашим и сторонним материалам (обычно базулька на Accesse писанная за часик). Просто невозможно было тратить время на форматирование внешнего вида документов согласно стандартам. Для нас главнее - содержание и доступность. Отформатировать специальным образом всегда можно потом, а в процессе разработки вполне хватало форматирования для удобочитаемости. Да и сами подобные документы - "живые организмы". Отливать из бетона в начале разработки нецелессобразно.
3. Блок-схемы, структурные и принципиальные... - это религия, тут нам инженерные бюро могли позавидовать.
Системный подход также является итеративным, с применением анализа на каждой итерации и корректирования результатов предыдущей (можно целую статью писать)
Так что, тоже, вроде, не граждане Непала. :)
|
