История
Версия для печати

Архив форума

Козлова Дарья 29.03.2006 20:07
Уважаемые участники форума, планируется создание нового портала посвященного Чемпионатам Урала по программированию. Хотелось бы услышать ваши пожелания по наполнению и функциональности такого сайта.

Заранее спасибо за ваши предложения.
Павел 30.03.2006 09:50
Цитата:
планируется создание нового портала посвященного Чемпионатам Урала по программированию.
Кем планируется? То есть какими средствами / чьими силами?
Кто будет поддерживать?
Какова вероятность, что планы перерастут в дело? :-)

В общем, хочется иметь более развёрнутую информацию о проекте перед тем, как начинать советовать.
Козлова Дарья 30.03.2006 11:53
Сайт будет разрабатываться в рамках дипломного проекта под руководством Гальперина Александра Леонидовича.
Планы самые серьезные.
Александр Клепинин 30.03.2006 13:49
Планы действительно серьезные.

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

То есть речь идет не о разовой разработке, а о создании базы для создания и дальнейшего развития единого портала олимпиадного движения УрГУ.
Павел 30.03.2006 18:51
В принципе, я могу сесть и собрать все свои разрозненные мысли в более менее стройную систему.

Но перед тем, как начать хотелось бы понять, действительно ли вам надо именно это? Может быть у вас уже есть какой-то план, мысли, идеи от которых нужно отталкиваться? Если есть, то хорошо бы было их озвучить ПЕРЕД тем, как спрашивать пожелания.

И ещё. Верно ли, что количество привлечённых средств и сил адекватно уровню серьёзности планов? ;-)
Я собственно первым своим постом именно это хотел выяснить.

PS. И вообще! Если уж третее сообщение позиционировалось как ответ на второе (моё), то почему в этом ответном сообщении нет ответов ни на один из поднятых мной вопросов?!
Александр Клепинин 30.03.2006 19:27
Павел:
В принципе, я могу сесть и собрать все свои разрозненные мысли в более менее стройную систему.
Это надо сделать. Каждый из членов нашего оргкомитета хорошо представляет ту часть работы, которой он занимается. И надо бы эти знания собрать в единую копилку.
Павел:
Но перед тем, как начать хотелось бы понять, действительно ли вам надо именно это? Может быть у вас уже есть какой-то план, мысли, идеи от которых нужно отталкиваться? Если есть, то хорошо бы было их озвучить ПЕРЕД тем, как спрашивать пожелания.
Первая задача - систематизировать то, что имеем, и понять, как это все можно объединить в рамках единого портала. На существующие системы посмотреть можно лишь в рамках функциональности, доступной обычному пользователю, администраторская функциональность просто так не видна. А учитывать при разработке нужно все. Поэтому я и посоветовал создать эту тему для сбора информации, накопившейся у каждого из нас.
Павел:
И ещё. Верно ли, что количество привлечённых средств и сил адекватно уровню серьёзности планов? ;-)
Я собственно первым своим постом именно это хотел выяснить.
Трудно сказать. Может быть до финала (готового портала) и не дойдем. Но это не повод не начинать. Будет основа, можно будет привлекать и других студентов. И точно знаю одно: если разработка будет вестись в отрыве от опыта оргкомитета, то она окажется нежизнеспособной, как предыдущий сайт ЧУ.
Павел 01.04.2006 20:07
Собственно, вот мои мысли!

Я так понимаю "портал" призван в конце концов заменить contest.ur.ru. То есть быть центром освещения и информационной поддержки всевозможных соревнований по спортивному программированию. По крайней мере я исходил именно из этого предположения.

Извините, что не текстом: думаю я именно такими картинками (MindMap-ами), а перекурочивать их в текст было лень. Да и жалко красоту портить :-)

Картина портала в целом (154 Кб)
Понятие соревнования в рамках портала (145 Кб)

Как и полагается, многие ветки недописаны. :-)

Исходники MindMap-ов. (232 Кб) Для просмотра исходников нужна программа MindManager.
Александр Мироненко 03.04.2006 15:13
Если я правильно понял слова "дипломный проект", то речь идет о паре месяцев, в течении которых не будет ни одного реального контеста. Соответственно мы получим некоторое количество никем не поддерживаемого кода, не испытанного в реальной работе. Оно нам надо?

В смысле, я согласен, что contest.ur.ru давно пора переделать, но реально отладка такой штуки займет весь сезонный цикл, т. е. год. Девушка на это готова? Кто из оргкомитета будет поддерживать этот код в дальнейшем?
Ботов Антон 03.04.2006 16:44
Александр Мироненко:
Если я правильно понял слова "дипломный проект", то речь идет о паре месяцев, в течении которых не будет ни одного реального контеста. Соответственно мы получим некоторое количество никем не поддерживаемого кода, не испытанного в реальной работе. Оно нам надо?

В смысле, я согласен, что contest.ur.ru давно пора переделать, но реально отладка такой штуки займет весь сезонный цикл, т. е. год. Девушка на это готова? Кто из оргкомитета будет поддерживать этот код в дальнейшем?
Да IMHO всё просто, ТЗ должно быть утверждено инициативным комитетом из тех, кто сможет это потом поддерживать, но у кого не хватает сейчас времени на написание кода. Код должен удовлетворять поставленному ТЗ, и быть написан в промышленном стиле - то есть с разумными названиями переменных соотносимыми с параметрами в ТЗ и хорошо прокомментирован. Код должен быть принят инициативной группой. Всё.

Со своей стороны готов выступить одним из участников этой инициативной группы. Все-таки какое-то время назад занимался коммерческой разработкой сайтов, хотя и давно это было.
Александр Клепинин 03.04.2006 17:26
Все верно. Речь идет о дипломном проекте. Да, времени мало. Да, я не строю никаких иллюзий относительно того, что полноценной системы за этот срок не появится. Но суть работы - именно подготовить проектную документацию, на основании которой затем можно было бы строить реальный сайт.

Фокус в том, что просто человек со стороны никогда не сможет сформулировать все, что нам нужно. И даже любой из тех, кто сейчас занимается поддержкой сайтов (contest.ur.ru, acm.timus.ru) не сможет описать всех деталей процесса (я, например, понял, что совершенно не представляю, как работает процесс регистрации командна contest.ur.ru; аналогично плохо понимаю, как сейчас используется рассылка сайта contest.ur.ru). Поэтому основная задача: попытаться собрать весь наш опыт в этом деле воедино, подготовить базу.

Задача непростая. Поэтому любые мысли, любые соображения очень ценны. И, кстати, были бы полезны сценарии обычных рутинных действий, выполняемых в рамках администрирования сайтов, пожелания того, как можно было бы оптимизировать эти действия.
Александр Мироненко 03.04.2006 18:01
Александр Клепинин:
Но суть работы - именно подготовить проектную документацию, на основании которой затем можно было бы строить реальный сайт.
Весь вопрос в том, кто именно потом будет "строить реальный сайт". Этим определяется какой объем работ надо включить в проектную документацию. Это и есть Пашин вопрос про ресурсы и серьёзность. Если у нас есть 1 относительно свободный человек на два месяца, а потом будут только вечно занятые члены огкомитета - то может было бы разумнее написать ТЗ ровно на два месяца и включить в него только самое насущное, чем написать идеал, который уже некому будет реализовывать?

В любом случае, хотелок и пожеланий у меня тоже навалом.

Следуя отечественной традиции "ТЗ пишет исполнитель", предлагаю исполнителю начать написание ТЗ, а мы по ходу написания поправим. И вести все это дело не здесь, а в CVS.
Ботов Антон 03.04.2006 21:23
Александр Клепинин:
Все верно. Речь идет о дипломном проекте. Суть работы - именно подготовить проектную документацию, на основании которой затем можно было бы строить реальный сайт.
IMHO:

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

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

PPS: И вообще на самом деле не ясно - есть ли смысл сразу весь сайт описывать? Может проще сначала описать ядро, пару модулей и интерфейсы для будущих модулей эскизно, а дальше делать ядро + эту пару модулей и вперед за дальнейшие модули браться - написали ТЗ, реализовали и т.д.
Павел 03.04.2006 21:41
Антон говорит очевидно (и очевидные) здравые мысли. У меня есть два дополнения:

1. Перед началом таки должен быть генеральный план действий. Непродуманный до конца, но широкий. Это чтобы понимать возможные горизонты развития. Какое-то подобие я и попытался нарисовать в своих рисунках.

2. Для такой постановки процесса нужен разумный и сильный координатор, готовый отдавать этому делу достаточно энергии и времени. Иначе, имхо, будет так: пока не станет окончательно очевидно, что портал никогда не станет жизнеспособным проектом, студенты под эгидой "великой цели" будут благополучно клепать дипломы.

Осталось придумать мотивацию для координатора. Пока что я таковую _очень_ смутно себе представляю. В научных руководителей в этой роли я не очень верю (наверное, даже "очень не"). Может быть что-то вроде хэд-хантерства потенциальных работодателей?.. сомнительно...
Александр Гальперин 03.04.2006 23:37
Цитата:
Перед началом таки должен быть генеральный план действий. Непродуманный до конца, но широкий. Это чтобы понимать возможные горизонты развития. Какое-то подобие я и попытался нарисовать в своих рисунках.
И получился очень интересный материал для размышления. Спасибо тебе, Паша, огромное, что потратил время и сделал это важное дело. Теперь твой план можо дополнять, продумывать дальше, детализировать, соотносить с имеющимися идеями и т.д.
Цитата:
Для такой постановки процесса нужен разумный и сильный координатор, готовый отдавать этому делу достаточно энергии и времени. Иначе, имхо, будет так: пока не станет окончательно очевидно, что портал никогда не станет жизнеспособным проектом, студенты под эгидой "великой цели" будут благополучно клепать дипломы.
Ни с кого из тех, кто поддерживает сейчас acm.timus.ru и contest.ur.ru, не сниут прямых профессиональных обязанностей. Поэтому, на мой взгляд, его никогда не будет. :( И как раз поэтому задача предстоящей работы заключается в том, чтобы продумать детали этого проекта; так сказать, подготовить в первую очередь проектную документацию с тем, чтобы в дальнейшем можно было эту схему наполнять руками последующих поколений студентов.
Цитата:
Тяжеловато будет, по сути проект должен состоять в том, чтобы выцепить всех людей обладающих знаниями на эту тему и вытряхнуть из них эти знания на бумажку, унифицировав их. Учитывая туманность дальнейших перспектив этого проекта, делать это будет весьма трудно.
Да, трудно, но делать это когда-то придется, иначе все загнется само собой, когда действующие члены оргкомитета по тем или иным причинам начнут откалываться от процесса, унося с собой знания об отдельных процедурах организационнного процесса.
Цитата:
PS: Вот если бы стояла очередь из студентов, который дальше брать куски из описанного проекта и качественно их реализовывать, было бы гораздо интереснее описывать.
А почему бы и нет? Очередь можно организовать. Лично берусь посодействовать в этом вопросе.
Цитата:
PPS: И вообще на самом деле не ясно - есть ли смысл сразу весь сайт описывать? Может проще сначала описать ядро, пару модулей и интерфейсы для будущих модулей эскизно, а дальше делать ядро + эту пару модулей и вперед за дальнейшие модули браться - написали ТЗ, реализовали и т.д.
На мой взгляд, это затруднит развитие всего проекта. Ведь идеи последующего развития могу напрочь перечеркнуть то, что уже сделано к какому-то моменту. Может получиться нечто, что придется из раза в раз переписывать заново.
Цитата:
В любом случае, хотелок и пожеланий у меня тоже навалом.
Я думаю, Дарье будет интересно их услышать. :)
Цитата:
Следуя отечественной традиции "ТЗ пишет исполнитель", предлагаю исполнителю начать написание ТЗ, а мы по ходу написания поправим.
Этот процесс в некотором смысле уже идет.
Павел 03.04.2006 23:42
В общем, первый контрольный срок - через 2 месяца.
С большим интересом слежу за развитием событий ;)
Ботов Антон 04.04.2006 01:10
Александр Гальперин:
Цитата:
PPS: И вообще на самом деле не ясно - есть ли смысл сразу весь сайт описывать? Может проще сначала описать ядро, пару модулей и интерфейсы для будущих модулей эскизно, а дальше делать ядро + эту пару модулей и вперед за дальнейшие модули браться - написали ТЗ, реализовали и т.д.
На мой взгляд, это затруднит развитие всего проекта. Ведь идеи последующего развития могу напрочь перечеркнуть то, что уже сделано к какому-то моменту. Может получиться нечто, что придется из раза в раз переписывать заново.
Если у нас нету опыта, чтобы учитывать наперед, то мы хоть запроектируйся, все равно чего нибудь забудем. А если опыт есть, то нет смысла детально описывать все модули с ходу. Это конечно IMHO, но основанное на опыте :).

По моему опыту нужно в ядре сайта учитывать следующие вещи:
1. Подключаемость модулей (в том числе взаимную - чтобы к модулю соревнования можно было подцеплять ленты новостей или часть новостей прикреплять к конкретным соревнованиям);
2. Система поиска по всему сайту;
3. Система навигации по всему сайту;
4. Подключение шаблонов (как всего сайта, так и модулей);
5. Порядок передачи параметров в модули при отправке форм и т.п.;
6. Система авторизации, группы пользователей и наборы прав;
7. Определить порядок публикации и сборки обычных страниц со вставками из модулей;
8. Определить порядок использования и хранения разнообразных меню (верхние/нижние/левые/правые);
9. Если будет нечего делать - сделать WYSIWYG-редактор для страниц;

Если все это аккуратно прописать и реализовать (что требует реализации вне модулей) - наклепать модули будет вообще не вопрос.

Неслабый список получился? Но это максимальный вариант. По сути база для любого корпоративного портала :)
Александр Клепинин 04.04.2006 17:24
Цитата:
Если у нас нету опыта, чтобы учитывать наперед, то мы хоть запроектируйся, все равно чего нибудь забудем. А если опыт есть, то нет смысла детально описывать все модули с ходу. Это конечно IMHO, но основанное на опыте
Ну, допустим, некоторый опыт есть. Если не в области разработки порталов, то по крайней мере в области разработки промышленного расширяемого кода. Так что не все так плохо. :)

Предложенный список более чем правильный. И именно подобную (расширяемую) структуру хотелось бы получить в итоге.
Цитата:
1. Подключаемость модулей (в том числе взаимную - чтобы к модулю соревнования можно было подцеплять ленты новостей или часть новостей прикреплять к конкретным соревнованиям);
Обычно делается так: регистрация модулей проводится при помощи центрального координатора (фактически, топология "звезда") с последующим предоставлением каждым модулем некоторого набора сервисов (например, провайдер ленты новостей - отличный пример подобного сервиса).
Вывод: у модуля должен быть внешний интерфейс, доступный другим модулям, позволяющий узнать предоставляемые им сервисы.
Цитата:
2. Система поиска по всему сайту;
Аналогично можно реализовать через механизм провайдеров. То есть модуль предоставляет интерфейс для выполнения операций индексирования и поиска.
Цитата:
3. Система навигации по всему сайту;
Вот это не очень понял. Общее дерево всех разделов? Тогда опять можно было реализовать через механизм провайдеров...
Цитата:
4. Подключение шаблонов (как всего сайта, так и модулей);
Вот слово "шаблон" нужно уточнять. Слишком много смыслов может быть. Пока что безусловно рассматривается возможность использования двух типов шаблонов: шаблон страницы (в рамках модуля) и шаблон соревнования (общая информация, информация для рубрикатора, принципы построения команд для модуля регистрации и т.п.)
Цитата:
5. Порядок передачи параметров в модули при отправке форм и т.п.;
Пропущено слово "основных". :) Фиксация формата нужна лишь для основных параметров. Плюс, имеет смысл вводить понятие пространства имен, чтобы исключить взаимодействие параметров разных модулей при отправке форм. Но, кстати, пространства имен в любом случае возникают, поскольку систему авторизации тоже надо строить по подобному принципу, когда права не зафиксированы заранее, а могут предоставляться конкретным модулем.
Цитата:
6. Система авторизации, группы пользователей и наборы прав;
Да. Это без вариантов.
Цитата:
7. Определить порядок публикации и сборки обычных страниц со вставками из модулей;
Пока предполагается такой подход: портал имеет некоторый внешний программный интерфейс, через который внешние модули (коннекторы) могут закачивать в портал информацию, собираемую из внешних источников. Подобная подкачка может выполняться в одном из двух режимов: премодерируемом и постмодерируемом.
Цитата:
8. Определить порядок использования и хранения разнообразных меню (верхние/нижние/левые/правые);
Скорее определить правила интеграции модулей в единое целое. Как следствие появятся правила формирования страниц портала, правила формирования меню и т.п.
Цитата:
9. Если будет нечего делать - сделать WYSIWYG-редактор для страниц
:)
Для начала было бы неплохо предусмотреть минимальный редактор, наподобие редактора задач на Тимусе.
Ботов Антон 04.04.2006 17:45
Александр Клепинин:
Цитата:
3. Система навигации по всему сайту;
Вот это не очень понял. Общее дерево всех разделов? Тогда опять можно было реализовать через механизм провайдеров...
В смысле - обычно на сайтах делают такие вещи как "строка навигации" или "карта сайта", очевидно что модули могут быть не только одностраничные типа "страница новостей", а еще и многостраничные типа "список соревнований", соответственно нужно в навигационной строке показывать "где мы сейчас" и генерировать соответствующую сайту "карту".
Александр Клепинин:
Цитата:
4. Подключение шаблонов (как всего сайта, так и модулей);
Вот слово "шаблон" нужно уточнять. Слишком много смыслов может быть. Пока что безусловно рассматривается возможность использования двух типов шаблонов: шаблон страницы (в рамках модуля) и шаблон соревнования (общая информация, информация для рубрикатора, принципы построения команд для модуля регистрации и т.п.)
В смысле дизайна сайта.
Александр Клепинин:
Цитата:
5. Порядок передачи параметров в модули при отправке форм и т.п.;
Пропущено слово "основных". :) Фиксация формата нужна лишь для основных параметров. Плюс, имеет смысл вводить понятие пространства имен, чтобы исключить взаимодействие параметров разных модулей при отправке форм. Но, кстати, пространства имен в любом случае возникают, поскольку систему авторизации тоже надо строить по подобному принципу, когда права не зафиксированы заранее, а могут предоставляться конкретным модулем.
Всё так, имелось в виду скорее не "порядок", а "принципы".
Cheetor 14.04.2006 15:05
Написать мощную и расширяемую систему с нуля за 2 месяца... Нереально. ИМХО. Выбрать один из существующих "порталов" с необходимыми характеристиками(настраиваемость, возможность написания функциональности как модулей и бесплатность для некоммерческого использования) и доработать под наши нужды - реально. Системы нужного уровня на коленках уже не пишутся.
Навскидку примеры: OpenCMS(Java), JBossPortal(Java), CommunityServer(.NET), *Nuke(PHP)
Всякое добро на Java: http://java-source.net/
Всякое добро на PHP: http://www.opensourcecms.com/ (Только мне сегодня достучаться не удалось)