Учебный проект № 2
Цели проекта:
1. Освоить грамотное использование ООП в проектах среднего размера: применение ООД, паттернов, UML.
2. Изучение рефакторинга и Unit-тестирования.
3. Изучение различных технологий создания ПО: языков, библиотек и т.д.
4. Освоение работы в команде удаленных разработчиков. Разработка методики на основе чего-то вроде Экстремального Программирования (XP).
Предполагаемые условия и средства разработки:
1. Язык разработки – Python. Язык лаконичный, гибкий, в комплект входят "батарейки", то есть, например, не надо искать модуль для Unit-тестирования – он уже включен. Есть сборщик мусора, что упрощает проектирование диаграмм классов, компонент и т.д. Отсутствие этапа компиляции делает более удобным метод создания программы маленькими шажками.
2. Операционная система – обсуждается. Кроссплатформенность предпочтительна.
3. GUI - wxPython. Обсуждается.
4. IDE: обсуждается. Хотя, я остановился пока на редакторе UliPad.
5. Репозиторий: SVN.
7. Сервер для репозитория – code.google.com. Обсуждается.
8. Средства общения: IRC, ICQ, форум.
Идея проекта.
Есть 3 идеи, которые мне могут быть интересны: редактор простейшей анимации, игра, программа регистрации данных. Опишу позже, если найдутся желающие принять участие. Главное, чтобы проект был менее абстрактным, чем предыдущий.
Участники:
1. Организатор. Пока я. Обязанности: освещать ход развития проекта, привлекать людей.
2. Разработчики: студенты, программисты-самоучки для которых и затевается этот проект. Обязанности: проектировать программу, писать код. Требования: уметь читать и понимать прочитанное, проявлять активность.
3. Кураторы: сами разработчики. Обсуждается.
4. Руководитель: нет. Обсуждается.
5. Возможно, художник. Художником могу быть я.
Приблизительная методика разработки:
1. Создается эскиз ТЗ, обсуждается.
2. Создаются эскизы диаграмм компонент, классов. Обсуждаются.
3. Каждый участник получает для разработки один (несколько) компонент из выбранной диаграммы.
4. Каждый участник становится куратором для другого. Он должен иметь доступ к коду курируемого, следить, чтобы тот "не лез в болото".
5. Код каждого участника выкладывается на всеобщее обозрение не реже, чем раз в неделю.
6. Если кто-то не успевает написать код, требующийся для других участников, то его код передается другому участнику в обмен на менее востребованный код.
Выгода:
1. Для разработчиков – опыт, новые умения.
2. Для меня - тоже. Бонус – шаг к созданию новых разделов :)
Жду критики, предложений, желающих присоединиться к проекту.
1. Раз уж питон, то почему бы не сделать кросплатформенно?
2. Как насчет моей идеи? Может ее попробовать? (Хотя мб слишком просто...)
3. С кем это все обсуждается, кто уже участвует?
Оно предпочтительно, но могут возникнуть трудности (GUI например не всегда одинаково выглядят даже у Java). Поэтому я не ставлю это обязательным требованием.
Мне кажется, что та идея для одного. Ну, можно конечно навертеть чего-либо поверх, но если ты решил делать приложение для телефона, то приложение должно быть простенькое, легкое.
Обсуждается со всеми у кого есть что сказать.
Оно предпочтительно, но могут возникнуть трудности (GUI например не всегда одинаково выглядят даже у Java). Поэтому я не ставлю это обязательным требованием.
а по мне, так это тоже неплохая цель для изучения, нет?
Мне кажется, что та идея для одного. Ну, можно конечно навертеть чего-либо поверх, но если ты решил делать приложение для телефона, то приложение должно быть простенькое, легкое.
да, пожалуй. хотя конечно я хочу потом сервис для компа написать и сделать синхронизацию.
Обсуждается со всеми у кого есть что сказать.
ясно =)
поэтому в течение пары минут родилась такая идея. раз уж проект в какой то мере под эгидой форума, то предлагаю написать удобную небраузерную читалко-писалку в форум. как это примерно выглядит, можно посмотреть здесь. Там, конечно, форум другой, но идея все равно одна.
Ладно. Опишу подробнее идеи. Хотя, они второстепенны.
1. Редактор анимации. Была у меня прога-плеер, в которой актеры-смайлики разыгрывали пьесы. Итого куча объектов: пьеса, актеры, фон, парики, шапки, мимика. Короче простор для ОО-проектирования. Если делать редактор, то поле деятельности еще шире.
2. Игра. Игру лучше взять простейшую типа многоклеточных крестиков-ноликов или лайнс. Также UAS предлагал сделать какую-то игру для ботов, которые будут программироваться игроками. В любом случае, игра - раздолье для ООП, подходящее применение.
3. Программа регистрации. Этот термин я взял со своей работы. То есть, это прога, которая получает данные от датчиков, записывает их в файл или базу, выводит на график, таблицу и т.д. Эту идею я взял по трем причинам: опять же много объектов, что позволило включить такой пример в книгу Буча, потенциальные участники могут уже применять подобные программы и их идея может заинтересовать, ну и понятно, что мне эти разработки могут пригодиться.
Но не важно, что за проект. Главное, не в том, извлечь выгоду от самого проекта, но от процесса его создания. То есть проект, должен включать кучу объектов, разнообразные взаимодействия объектов. Такой мой критерий выбора.
1. Опыт.
2. Знания.
3. Продукт.
В случае написания чего то подходящего для обучения, но в основном для использования бесполезного - мы теряем третий пункт, а значит и КПД.
ps. Вот ведь завернул то...
Начну с образного выражения, потом поясню.
Я говорю: пойдем в спортзал и накачаем мышцы.
Ты говоришь: вместо того чтобы бессмысленно гири поднимать лучше бы бабушке натаскали воды в ведрах. И польза и сила.
Но у бабушки водопровод - ей эта помощь не нужна, а таская ведра мы качали мышцы бессистемно и нормального рельефа мышц не вышло.
Пояснение. Можно выделить 3 типа программ: утилиты, программы среднего размера, крупные программы. Есть и другие типы, наверное.
Утилиты подразумевают копание в конкретной технологии (всякие протоколы, API операционных систем и т.п.), которая нигде может не пригодиться больше. Этим может заниматься и новичек почти наравне с бывалым программистом. Вот про них ты и говоришь. Здесь не нужно почти никакого ООА, ООД, ООП и т.д. Необходимость в них тут не очевидна.
Крупные программы - эта та область куда я даже не смотрю пока. Это те же ММОРПГ. Понятно, что этого не осилить. Но в таких программах как раз и применяется ООА, ООД, ООП, всякие рефакторинги, юнит-тестирование и т.д.
Но так как крупная программа не является удачным объектом для учебного проекта, то я смотрю в сторону средних, примеры которых я и привел. Это и осилить проще и есть где навыки проектирования программ прокачать. Плюс к тому - я смогу написать хоть какое-то ТЗ для них, что достаточно важно.
Мне не нужен продукт, который прославит меня среди пользователей, мне нужен хороший тренажер проектировщика программы, на котором я бы научился строить диаграммы UML, проникся смыслом ООП, понял, как применять всякие рефакторинги. Если найдутся люди, которые думают также - то и хорошо. Вместе проще учиться.
Конечно, хорошо бы сочетать полезное с полезным же. Но полезность для пользователя - вещь второстепенная, даже третьестепенная в данном случае.
Которые сферические и в вакууме.
надо найти такую бабушку, у которой водопровода нет.
upd.
я не настаиваю на своих идеях. но идеи когрома не видятся мне какими то особо полезными или нужными чтоли, без обид. =)
поэтому предлагаю чтобы народ подсказал еще что-нибудь. чтобы что-то средненькое, чтобы было на чем поучиться и чтобы конечный продукт можно было использовать во благо человечеству. =)
Иначе говоря, я получу модель, которая будет далека от жизни?
Это не так. Даже прошлый абстрактный проект научил меня кое-чему. Например, раньше я не мог представить, как разделить один проект на несколько исполнителей. Теперь представляю. Правда, не каждый проект для этого подходит.
Далее. Как-то Der Meister сказал, что разобраться с замороченными UML-диаграммами ему интереснее, чем решать студенческие задачки. Не знаю, интереснее это или нет, но решаем мы тут только студенческие задачки + тонкости каких-то технологий, протоколов. Поэтому я и ищу проект, в котором можно было бы прокачаться в составлении и усовершенствовании таких диаграмм.
Ну, а мне не кажутся интересными твои. Тоже без обид :)
Но я знаю людей, которым пригодятся мои идеи №1 и №3. Вторую идею я особо не осмысливал, взял ее из-за популярности + было подобное предложение от UAS.
народ, человечество... ну их. Было бы это нужно самим участникам проекта. А то Washington развел тут флейм, а сам не собирается участие принимать.
Потому у меня простое предложение: построить эскизы диаграмм компонентов (или классов) для каждого проекта (идеи). Если по диаграмме не будет видно, как разделить проект на несколько человек - то в топку проект. Если диаграммы не будет - то в топку проект.
И потом, зря сосредоточились на проектах. Тут есть некоторые другие опасные моменты. Например, выбранный язык наверняка пугает потенциальных участников. Можно обсудить этот пункт. Или GUI. Например, в IRC Romik предложил использовать web GUI. И это интересно. Хотя, теоретически можно сделать проект с двумя GUI.
Про IDE наверное нет смысла говорить - оно должно влиять на код только косвенно, потому тут каждый может выбрать на свой вкус.
Ну, а мне не кажутся интересными твои. Тоже без обид :)
Но я знаю людей, которым пригодятся мои идеи №1 и №3. Вторую идею я особо не осмысливал, взял ее из-за популярности + было подобное предложение от UAS.
да я не настаиваю на своих. хотелось бы послушать, что думаю другие. может у кого то найдутся другие идеи, которые стоило бы обсудить.
народ, человечество... ну их. Было бы это нужно самим участникам проекта. А то Washington развел тут флейм, а сам не собирается участие принимать.
ну может и приму в каком то виде. кто знает. (сейчас приходится проходить много жизненных квестов, поэтому времени не особо хватает, но все же). но если мне не понравится идея, то конечно участвовать не захочу вообще.
Потому у меня простое предложение: построить эскизы диаграмм компонентов (или классов) для каждого проекта (идеи). Если по диаграмме не будет видно, как разделить проект на несколько человек - то в топку проект. Если диаграммы не будет - то в топку проект.
ну а кто будет строить? я для своего проекта точно не смогу - не умею. учиться особо сейчас в этом направлении точно не буду.
Про IDE наверное нет смысла говорить - оно должно влиять на код только косвенно, потому тут каждый может выбрать на свой вкус.
кстати я тоже подумал. сделал простенькое окошко с помощью wxWidgets, оно запустилось и в wxGlade, и в Idle Python, и в Netbeans. Так что, похоже, IDE на код почти не влияет.
Насчет веб гуя - хороший способ осваивать питон в его web-ипостаси =)
Ну, я же не требую, чтобы они были по правилам UML. Можно делать как у Буча. Или свои правила для диаграмм придумать на ходу. Но тогда придется писать пояснения.
Я не требую, чтобы они были красивыми. Может быть набросок типа того, что находится тут.
Хм. Внезапно я понял, что придется составить список литературы, которая пригодится для проекта, чтобы было понятно, к каким целям я стремлюсь.
Кстати, ООП-то будет function-oriented или message-oriented? Я за второй, например.
Вот нагуглил интересную статью:
http://citforum.univ.kiev.ua/programming/python/python8.shtml
Уже хорошо. Только эта идея пока самая расплывчатая. Ее я вычислил из следующего сообщения:
Т.е. допустим, выбираем те же шахматы. Каждый пишет свои алгоритмы на любом своём языке. А игра будет типа по сети) Естессно, прога каждая сама должна хранить у себя результаты, игра на честность, конечно.
Понимаю, что крайне натянуто всё, но всё же так намного интересно - ведь тут уже не просто проги пишешь, а уже соревнуешься. Тут уже и оптимизация будет, и т.д.=)
Вообщем, что-то типа такого. Может, если придумаем че толковое, то можно собрать народ, что-то придумать и посоревноваться)
Но как оно будет выглядеть - пока плохо представляю.
Не дедлайн в неделю, а выкладывание кода хотя бы раз в неделю. То есть, другие участники должны видеть, что ты делаешь, чтобы вовремя помочь, что-то подсказать, поправить. Иначе работа в команде теряет смысл.
Ну, я зацикливаюсь на том, что изучаю. ФП, МП (модульное?) я не запрещаю, но для меня пока приоритетом является ООП.
мета
Это радует, а кроме того, ведь локальные решения на других парадигмах негативно могут повлиять только при неправильной инкапсуляции - типа такого что-то.
Слышал, что майкрософт делал нечто подобное. У них там была игрушка с программируемыми роботами, игрок занимался написанием ИИ. Конечно, не на разных языках.
Нечто подобное:
http://en.wikipedia.org/wiki/Robocode
статью глянул - пока ничего не понял :)
На счет function-oriented или message-oriented не совсем понял терминологию. Но в разных частях программы могут быть применены разные паттерны. Подозреваю, что будет и то и другое.
Робота-собирателя десантируют на некоторой планете, его задача - добыть какие-то полезные ископаемые. Но ландшафт на планете не ахти какой, а кроме-то, имеются всяческие гейзеры, ямы, газы, разьедающие металл и тп. Информацию о окружающей среде робот получает исключительно визуальную и сам изначально умеет её интерпретировать: имеется field of view, обьекты в котором он осмыслил и оценил расстояние до них. Задача игрока - запрограммировать поведение робота таким образом, чтобы вне зависимости от окружающей среды он нашел и добыл ресурсы и добрался до нужной точки, где его заберут.
Задача, возможно, станет актуальной для человечества в будующем :)
В качестве языка программирования робота проще всего юзать скорее всего сам питон (там же наверняка есть какой-нибудь eval) - а чтобы было удобно, написать на нём тулкит для игрока.
Message-oriented, это всмысле когда методы вызываются посылкой обьектам сообщений, типа как в smalltalk, common-lisp-object-system и objective-c, а function-oriented - это вызовы как в c++, c#, java и тп.
Ну и хорошо. Можно развивать эту тему.
Я буду упрощать условия. Предлагаю игру сделать двумерной, на карте размещать одного робота. В дальнейшем можно будет размещать по несколько роботов на карте, если что-то получится с одним.
Есть, но его страшновато использовать в чистом виде :)
Так как я программист на C++, то и подходы мои соответствующие будут. Но я поддаюсь переубеждению. Посмотрим.
В качестве языка программирования робота проще всего юзать скорее всего сам питон (там же наверняка есть какой-нибудь eval) - а чтобы было удобно, написать на нём тулкит для игрока.
нечто саморазвивающееся? при выполнении некой операции, возвращающей положительный результат, анализируется ситуация и генерируется некий код, который модулирует поведение робота в подобных ситуация, записывается куда нибудь, а затем вызывается eval()'ом? =))
Message-oriented, это всмысле когда методы вызываются посылкой обьектам сообщений, типа как в smalltalk, common-lisp-object-system и objective-c, а function-oriented - это вызовы как в c++, c#, java и тп.
а чем мессэдж ориентед лучше любимого и родного фанкшн ориентед?
Да с 3д мы бы совсем запарились :)
Ну это уже от игрока зависит: с таким подходом пространство для фантазии и МП огромно :)
Тем, что классы могут просто игнорировать некоторые сообщения, а некоторые - перенаправлять. Ну и гораздо проще отправить сообщение разным обьектам, чем приводить к обобщенному, поддерживающему некий интерфейс и вызывать функцию.
Кроме того, составлю примерный список книг, которые я намереваюсь использовать в проекте.
Питон я хоть и не знаю, но поучиться не прочь. Вообщем, чем помочь пока что - точно не знаю. Время у меня вообще распределено по-дурацки, но постараюсь вникнуть в суть дела и хотя бы раз в неделю отписываться=)
Вообщем, я не против поучаствовать. Идея тоже нравится.
На карте находится робот и объекты нескольких типов. Карта представляет собой расчерченное на клетки поле. Каждый объект занимает 1 клетку.
Робот имеет 2 ресурса: минералы и время. Минералы он находит на карте, время является мерилом эффективности робота. Время измеряется в ходах. Чем меньше ходов сделает робот для сбора всех (или определенного количества) минералов на карте, тем более эффективен он для этой карты.
Объекты бывают трех основных типов: добавляющие минералы, отнимающие время и пустые. При этом, пустые и добавляющие минералы исчезают, когда робот занимает их клетку, отнимающие время — не исчезают.
Отнимающие время делятся на 2 типа: стены и ямы. Стена не пропускает робота, отнимает ход, если робот пытается занять ее поле. Все стены одинаковы. Карта огорожена со всех сторон стенами.
Яма отнимает у робота несколько ходов, если робот наступает на нее. Типы ям отличаются тем, сколько ходов они отнимают у робота. Иногда роботу выгоднее пройтись по яме, чем обходить её.
Каждый объект имеет свое имя и свойства. Все объекты с одинаковыми именами имеют одинаковые свойства. Робот различает объекты по именам, но вначале игры он не знает свойств объектов.
Пример: объект с именем А — стена, объект с именем Б — минерал, В и Г — пустые объекты, Д - яма отнимающая 3 хода, Е, Ж — ямы, отнимающая 5 ходов и т. д.
Робот видит вокруг себя только на одну клетку. Но он может помнить, пройденную зону (если это предусмотрит программист). Это может быть полезно, так как объекты не двигаются.
Робот имеет определенное направление. Робот должен потратить ход, чтобы повернуть вправо или влево. Робот должен потратить ход, чтобы переместиться на одну клетку вперед. Робот может потратить ход, чтобы выяснить свойства объекта, стоящего перед ним.
Так всё в первом посте расписано, а потом объяснено еще раз. Почти тоже самое, что и в первом учебном проекте. Но тут я хотел исправить некоторые организационные и технические ошибки.
Организационные: недоступность кода некоторых участников для других.
Технические: язык не очень подходящий для учебного проекта. Например, в прошлый раз я спотыкнулся на кривых инструментах для Unit-тестирования в C++. Да и отсутствие сборщика мусора немного отвлекает от понимания процесса. Структура с файлами-хедерами тоже добавляет ненужные детали. И т.д. В общем, C++ хорош для "настоящих" проектов, но не очень для учебных.
Ну, в прошлый раз все-таки вышло что-то, так как никто не предлагал сделать "ММОРПГ" (утрирую немного), не предлагал свои прожекты. Тупо взяли недописанное ТЗ кота, дописали и стали реализовывать. Сейчас нету такого ТЗ вот и приходится что-то выдумывать.
Но про codenet fail ещё рано говорить.
http://www.iso.ru/journal/articles/253.html
http://www.iso.ru/journal/articles/294.html
Вот еще нагуглил учебник:
Учебник Python 3.1
И еще: возможно, следует использовать какие-то другие средства коммуникации - кроме форума? У меня, например, созрело пару вопросов по питону, на которые пока не получается нагуглить ответ.
http://www.iso.ru/journal/articles/253.html
http://www.iso.ru/journal/articles/294.html
Вот еще нагуглил учебник:
Учебник Python 3.1
Особого внимания заслуживают ученые степени авторов первой статьи да и второй тоже.
Технические: язык не очень подходящий для учебного проекта. Например, в прошлый раз я спотыкнулся на кривых инструментах для Unit-тестирования в C++. Да и отсутствие сборщика мусора немного отвлекает от понимания процесса. Структура с файлами-хедерами тоже добавляет ненужные детали. И т.д. В общем, C++ хорош для "настоящих" проектов, но не очень для учебных.
А вот здесь симулятор стрельбы по уткам находит свое подтверждение.
Да там переводчик - дурак. Ph.D., по-нашему, - это доктор наук.
http://www.iso.ru/journal/articles/253.html
http://www.iso.ru/journal/articles/294.html
Интересненькие ссылки, правда изложение темы чудовищно запутано.
+1. у меня например вообще музыкальное образование, но программировать оно не мешает. Разве что под оцтойную музыку. =)))
Я за то, чтобы использовать Python 2.6. Дело в том, что вторая и третья ветки Питона (именно ветки, а не версии) не имеют совместимости. Но для второй ветки есть куча библиотек (в том числе и для GUI), книг, документации, исходников. Многое ПО, используемое для разработки на Питоне (IDE например), которые сами сделаны на Питоне также не будут работать с третьей веткой.
Я не сильно отклонюсь от правды, если скажу, что третья ветка пока экспериментальна.
Конечно. Новый раздел ты уже нашел. Еще есть IRC, ICQ. Washington предлагал сделать канал на Джаббере.
Но перейду к делу. Вроде бы, определились что делаем: игру с роботом. Так? Надеюсь больше споров не будет.
По науке, следующим пунктом должно быть написание наброска ТЗ. Затем должен быть этап создания эскизов диаграмм. И только потом надо приступать к коду. Я понимаю, что некоторым охота сразу попробовать разные трюки и хитрости в Питоне, но это можно сделать в маленьких задачках. Здесь же лучше делать всё по порядку.
Так вот, я предлагаю обсудить ТЗ. Кое-какие наброски я уже выкладывал в теме, но пока они остались без комментариев.
Korgom, если хочешь вести подобный проект при данных условиях, то каждое своё движение обсуждать, мягко говоря, не надо. Подобного рода затеи, заканчиваются либо до начала написания ТЗ (никак обсуждения не закончим), либо в процессе написания ТЗ (сплошные обсуждения взамен работы). Дальнейшая работа, дойди она даже до кодинга, будет представлять собой - разброд и шатание.
У вас получается, что рабочие должны сами себе работу придумывать, и потом её работать. Оторванный от реальности, здравого смысла и человеческой натуры шаблон.
P.S. Тема интересная. Я поэтому и влезаю, что хочется увидеть развитие хоть какое-то - хоть чего-нибудь.
Первое критическое сообщение в этой теме, которое я признаю логичным :)
Однако, думаю что можно попытаться диктатуру лидера заменить на диктатуру регламента, правил. Ну или сочетать их. То есть до итерации составления требований надо составить сами правила разработки.
Постараюсь составить правила на основе методик типа:
http://ru.wikipedia.org/wiki/Итеративная_разработка
http://ru.wikipedia.org/wiki/Rational_Unified_Process
Ну и эту книгу возьму в помощь:
Крэг Ларман, Применение UML 2.0 и шаблонов проектирования.
Рекомендую и другим участникам её посмотреть. Там помимо прочего рассказывается про итеративный процесс разработки.
Время на итерацию составления и обсуждения правил - до 05.10.2009.
Если у кого-то есть опыт работы по подобным методикам прошу поделиться рекомендациями.
Рекомендуемая литература:
1. Мартин Фаулер, UML. Основы.
2. Крэг Ларман, Применение UML 2.0 и шаблонов проектирования.
3. Кент Бэк. Разработка через тестирование (TDD).
4. Мартин Фаулер, Рефакторинг.
5. Марк Лутц, Изучаем Python.
Дополнительная литература:
1. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес, Паттерны проектирования.
2. Кент Бэк, Экстремальное программирование.
3. Гради Буч, Объектно-ориентированный анализ и проектирование.
4. Фредерик Брукс, Мифический человеко-месяц.
В принципе, книгу про паттерны можно перенести в основной список.
Остальным участникам (если они не разбегутся после моих последних сообщений) рекомендую хотя бы ознакомиться с UML, TDD и основами рефакторинга. Ибо эти средства как раз в крупных (и средних) проектах интересны.