Это не описание реализации, это вопрос к сообществу на чем лучше реализовывать.

Есть вот какая задача:
Загрузка на сервер и хранение цифровых образов размерами до 1,5 Гб, наряду со стандартными фотками, а также видео и аудио материалами (далее объекты хранения). Необходимо организовать более продвинутое хранилище, чем просто хранение в файловой структуре. А именно генерировать превьюшки с изображений, в том числе, в некоторые моменты, генерировать изображения для DeepZoom, делать конвертацию в swf для предварительного просмотра видео. Ну, с аудио вопросов нет, прослушивание его и так прикрутить можно.

Вопрос к Хабрасообществу.

Есть высококачественное изображение, какие есть решения по поводу представления пользователям просмотра этих самых изображений по фрагментам с видимой областью где-то 500х500px?

Какие есть требования/пожелания:
Исходные изображения 5-10Мб jpeg
Учет каналов пользователей по всей России, т.е. от широкополосного до ADSL с ограничениями 128 и т.д.
Защита от скачивания целого изображения
Желательно использование некоторого готового решения для этих целей.

Не идет речь о создании платного сервиса, проект социальный — тема изображений произведения искусства (живопись, графика, книги).

Что первое приходит на ум:
1) организация присмотра типа googlemaps
2) использование SilverLight/Flex
3) Использование Java апплета

Что смущает:
1) Google есть Google, где-то слышал об использовании движка Maps для этих целей, но наверное будет трудно с ними договориться, по крайней мере пока не представляю как.
2) Придется с нуля писать на незнакомой технологии.
3) Вообще темный лес, пугает стоимость специалистов в этой области.

Что посоветуете, на какие технологии обратить внимание, какие тенденции в плане пользовательского интерфейса?

Как человек с техническим образованием, да и техническим складом ума, пожалуй, я осознаю необходимость планирования текущей деятельности и задач. В большинстве прочитанной литературы по управлению временем и повышением личной эффективности советуют писать долгосрочные планы личностного развития: месяц, год, жизнь. При этом надо сформировать действительно достойные цели и задачи на указанные сроки.

Я также осознаю, что развитие личности не должно быть однобоким, т.е. наряду с техническими умениями и знаниями надо бы не забыть про творческое и гуманитарное. (Скажите, много ли вы знаете IT-шнегов, которые могут назвать когда открылся 1-й Белорусский фронт, к примеру, или основное творение Нерона – не софт для записи CD). А творчество, по моемому, очень плохо поддается планированию, да и сами творческие личности не особо дружат с данной категорией. В общем-то, я их понимаю.

Так вот, вопрос ответа на который я пока не нашел, это насколько нужно следовать парадигме, чтобы не впасть в параною и в тоже время нормально развиваться. Не спрашивайте, что вкладываю в понятие нормально, это совсем другая история.

Изобретение велосипеда PHP программистами, под которым подразумевается написание собственной CMS, является, наверное, краеугольным камнем, как для разработчиков, так и для пользователей. Появились такие сайты как cmslist.ru, smagazine.ru, да и просто количество CMS за последние пол года, год увеличилось на порядок. Собственно анализ данной ситуации – совершенно другая сказка. А вот построение идеальной CMS или некоего высшего принципа построения таковой, агрегирующей в себе большинство достоинств и минимум недостатков, вопрос, ответ на который интересен, наверное, не только мне, но и многим разработчикам.

Преамбула. (Часть 1)
CMS — Система управления содержимым[WiKi], исходя из своего названия говорит уже о многом:)

Тут можно, наверное, сразу же предположить деление CMS по признаку используемого контента:
обычный текст;

• структурированные данные (новости etc.);
• большое количество структурированных данных (каталог продукции с характеристиками), объединенные общими данными (справочниками).

Далее, углубляясь в расширение работы с пользователями, можно предположить необходимость дополнительных сервисов – регистрация (личный кабинет), интернет-магазин, возможность оставлять комментарии, создание опросов, форум etc.

Пару слов, по поводу типовых условиям использования и видов заказчиков. Не побоюсь такого деления заказчиков на две большие группы такие как:

• те которые хотят сайт и инструмент управления, но мало представляют себе как все это должно быть;
• и тех кто CMS использует по полной программе;

Вот такое, казалось бы, глупое и не форматное деление, но давайте посмотрим подробнее, что же имеется в виду, ибо четко в двух словах выразить мысль не просто:

• Есть такие заказчики, которые имеют объем информации для сайта, управление этой информацией планируется силами секретарш или силами разработчика, развитие нового функционала не планируется, а если и планируется, то по любому за счет разработчиков CMS.
• А есть, к примеру, такие, которые обладают специалистами могущими собственными силами наполнять, поддерживать, развивать.

В общем-то такое деление заказчиков обуславливает еще один тип деление CMS, а именно:
простота внедрения и дальнейшей разработки;
или же простота управления, в виде легкого написания контента, и нафиг все доп. модули, ибо сложно;

Ну и, самое, неочевидное деление по типу устройства админки и самого движка CMS. CMS представляющие собой формирование страницы на лету, путем сборки по шаблону средствами скриптового языка из базы;
и некоторое количество CMS основанные на публикации страниц в статический html;

Итого:
Вопрос, господа хабрачеловеки, имеет ли место быть все вышеизложенное и будет ли интересен дальнейшее рассмотрение предпосылок для создания и вариантов построения некой идеальной CMS?

UPD0:
Абсурдность идеала была понятна и до написания, ясно что без трансформации мыслеформы в результат идеал сомнителен. Однако, на мой взгляд, такой концентрации мысли, что бы не получился в итоге мусор еще надо достичь, но это уже философия.

Но, идеал представлялся мне как агрегация наиболее оптимальных решений, и в первую очередь для разработчика, именно с этим и была попытка у хабраобщества уточнить подходы и реализации, у хабраобщества, как сообщества разработчиков. А получился в комментах взгляд со стороны заказчика, обидно…

Управление проектами в разных его вариантах описано в большом количестве литературы, и все авторы имеют свой оригинальный взгляд на этот процесс. Прочитав не один талмуд и ведя ни один проект хочу представить и свой взгляд на этот процесс, в части проектирования проекта что, на мой взгляд, мало описано (все увлекаются описанием непосредственно процесса, а он сам и его качество не в последнюю очередь зависит от того как все было спроектировано).

Все управление можно представить как и стек протокола TCP/IP, разложив его про уровням взаимодействия вовлеченных в процесс субъектов и объектов.

Так можно выделить

• идейный
• коммуникативный
• и проектный уровни

К идейному относится все то, что является самой сутью проекта (чего хотим добиться и какие у него свойства). Трудно структурировано представить этот уровень, но это, в первую очередь, общение на этапе «Слушай тут есть классная идея…» или «Вот, нам тут надо…». Тут самое главное опыт самого РМ, который позволит разграничить необходимые и маловразумительные сомнительные желания (они же в дальнейшем характеристики) проекта. Понять и объяснить реальность воплощения тех или иных идей, не исключено что уже тут станет ясно, что по чем. Общение, общение и еще раз общение, со всеми смежными с проектом и могущими в нем участвовать спецами и дилетантами. Дилетанты опишут суть в двух словах – больше они и сами не знают, а суть им так или иначе рассказали. Спецы – посвятят в тонкости и нюансы.
Само собой РМ должен быть специализирован на какой-то области, уверяю вас — РМ интернет стартапов будет жалко смотреться на производстве ЖБИ.

На коммуникативном уровне решаются вопросы как и каким образом весь этот бардак предыдущего уровня, да и последующих, будет управляться в смысле людей и их взаимодействий. Тут есть обязательные, на мой взгляд, для участия субъекты. А именно: ответственный субъект со стороны заказчика, ответственный субъект со стороны исполнителя и идеолог проекта. Как и в какой степени три этих субъекта будут трансформироваться в конкретные личности – дело ваше, но по возможности старайтесь избегать совмещения ответственного субъекта со стороны исполнителя и идеолога проекта в одном лице – иначе в случае завала работ идеологом (ибо люди либо творческие, либо ОЧЕНЬ занятые) у вас не будет возможности влиять на него через ответственного со стороны заказчика.

Из ранней практики:
Проект с постоянно меняющимся ТЗ. В проекте были сомнительные в плане стороны исполнителя задачи по работе с исходными данными. При этом необходимость решения данных задач осознавали все участники проекта. Будем думать, что участие заказчика в выполнении задач проекта объяснять нет необходимости. Так вот исполнитель был и не против взять на себя решение этих задач, за отдельную плату, соответственно. Заказчик долго принимал решение по этому поводу, меняя решение, попутно пытаясь сам что-то делать. В итоге без исходных формализованных данных дальнейшая работа была невозможна, а воз и ныне там. Проект заглох сам собой…

Старайтесь сразу определить степень бюрократичности, а именно какие решения и как будут фиксироваться и подтверждаться актами, протоколами и etc. Избежать бумажного подтверждения совсем не удастся (должны быть хотя бы роли и ответственность), превращать проект в работу бюрократического аппарата тоже нет смысла. Но если в проекте есть вероятность задержки от постоянно меняющихся данных со стороны заказчика, а сроки проекта жесткие и заказчик каждый раз приносит что-то новое и противоположное предыдущему ¬ вам не обойтись без фиксирования этих этапов, с указанием смещения сроков проекта. И если сразу нет договоренности о подписании протоколов и других документов, вы можете получить очень конфликтную ситуацию, решив в середине проекта подписать решение заказчика. Придется работать с тем что есть и вся ответственность о срыве проекта ляжет целиком на вас.:-(

Рабочий уровень касается непосредственно работ, когда наступает момент «фигачить и фигачить» На этом уровне работают все современные модели управления проектом, водопадный, эджайл и т.д. Выбор за вами.

Вместо заключения:

На практике все приобретает очень трансформированный вид относительно теории.
Я вывел для себя некоторые пункты без которых проект – неблагодарное занятие:

• 1) Понимание круга вовлеченных в проект и меры ответственности с подтвержденным в бумажном виде вариантом;
• 2) Понимание круга задач и стороны исполнителя этих задач также с подтверждением этого на бумаге;
• 3) Понимание степени формализации процесса и модель взаимодействия;
• 4) Фиксирование контрольных сроков и зависимость от наличия или отсутствия исходных данных и соответственно сдвиг конечной точки от даны подписания конечного варианта или его изменения после.