Забегая вперед, скажу, что работу я представил на ежегодной конференции проектных работ в школе, на конференции "Intel-Династия-Авангард" и на Балтийском научно-инженерном конкурсе Intel. Хотя тема проекта (разработка эмулятора стековой машины и набора инструментальных средств к нему) не претендовала на большую оригинальность, работа над ней и последующее представление в любом случае были для меня полезным опытом: до этого мне не приходилось выполнять проектных работ по программированию, как и участвовать в конференциях по данной тематике.

Участие в крупных Всероссийских конференциях, вроде "Авангарда" и Балтийского научно-инженерного конкурса, имеет свою специфику. В частности, помимо собственно разработки приложения, необходимо подготовить сопроводительные материалы к проекту, такие как тезисы, достаточно подробную статью, презентацию, ну и, конечно, демонстрацию результатов. Для участия в школьной конференции было достаточно тезисов, презентации и демонстрации.

Работа над проектом

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

Напротив, если проект является лишь еще одной работой, которую необходимо выполнить, это взывает к дисциплинированности и заблаговременному выполнения всех пунктов "to-do-листа". Действительно, если нет уверенности, что завтра будет время, чтобы завершить работу над статьей (например, над этой), создается мотивация для того, чтобы закончить ее сегодня.

На Балтийском конкурсе один скептически настроенный член жюри задал мне вопрос о влиянии работы над проектом на мою успеваемость (видимо, этот вопрос является насущным для многих участников). Он считал, что ведение достаточного сложного проекта, требующего регулярно уделять программированию определенное время, неизбежно приведет к падению успеваемости по всем предметам, кроме информатики. Я ответил, что если работа над проектом каким-либо образом сказывается на успеваемости по другим предметам, это в первую очередь говорит о неорганизованности самого исполнителя работы, а не о работе как таковой. Во-первых, исполнитель неверно оценил свои силы, когда соглашался на выполнение проекта такой сложности; во-вторых, не продумал вместе со своим руководителем "запасные варианты" в проекте, которые позволят снизить сложность работы; и в-третьих, уже во время работы, он "дотягивал" до таких критических ситуаций, когда своевременное выполнение проекта могло быть достигнуто только в ущерб учебе. Что касается меня лично, то никакого снижения успеваемости проект не вызвал.

Большое значение имеет общение по теме работы и доклада с научным руководителем, консультантами, старшими братьями и сестрами, родителями и просто заинтересованными лицами. Равно ценны как поддержка, так и критика — как от специалистов, так и просто от "сочувствующих". Это помогает держать нужную траекторию работы, не зарываясь в мелочи, но и не уходя, как в анекдоте, в "сферический вакуум", сохранять уверенность в успехе и не скатываться в убогое качество работы. Ну и исправлять многочисленные ошибки, неточности, погрешности и опечатки, которые свойственны человеку и появление которых в любой работе неизбежно.

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

В общении со своим научным руководителем никакого принуждения я не заметил. Были предложения и мотивации, была разумная требовательность (и она очень пригодилась впоследствии на конференциях всероссийского уровня), но принуждения, "олимпиадного" давления, связи с оценками никоим образом не было. Был даже один раз, когда в декабре школьная конференция (проводившаяся тогда в лицее "Вторая школа") была неожиданно для всех участников смещена на две учебные недели вперед администрацией лицея (а потом она так же неожиданно была перенесена на январь), я понял, что за сократившееся время не смогу подготовить хорошей презентации и доклада, и решил отказаться от участия. Тут не было моей вины, никто не знал, что так произойдет. Мой руководитель понял мое нежелание жертвовать качеством работы и не стал настаивать. Он сказал, что это вполне взвешенное решение, и он вполне понимает его, что, отчасти, для меня было неожиданно: где-то в глубине души, по школьным привычкам, ожидал, что "будут ругать".

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

Далее я постараюсь кратко описать и сравнить три конференции, в которых мне довелось участвовать в этом году.

Школьная конференция проектных работ

Из всех трех перечисленных конференций именно секция компьютерных наук "родной" школьной конференции — самая спокойная и дружелюбная. Главное, что в ней нет того неприятного оттенка соревновательности, присущего другим конкурсам, поскольку на ней нет понятия победителей. И до конференции, и во время нее, и после — все равны. Вопросы докладчику после выступления, задаются не с желанием "завалить" его работу, а только разобраться для себя в сложных местах. И поэтому вдвойне хорошо, что эта конференция проходит первой в году из всей череды конференций: именно на ней можно без риска и суеты "протестировать" доклад, узнать мнение аудитории, услышать вопросы, которые впоследствии могут быть заданы на других конференциях, исправить непонятные места доклада и презентации. Обычно она проходит в начале декабря, и после нее есть время улучшить работу. В этом году она проходила за неделю до "Авангарда" и за две недели до "Балтики", что, к сожалению, привело к "гонке событий" и работа почти не дорабатывалась между конференциями.

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

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

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

Труды конференции (сборники, презентации, аудиозаписи докладов и другие материалы) выкладываются на сайт http://ded32.net.ru, где много примеров различных проектов и докладов, которые полезно смотреть, готовя свою презентацию.

Конференция "Intel-Династия-Авангард"

Эта конференция проходит в январе, и для приезжих участников длится восемь дней. Мы же, как участники из Москвы, были только на двух днях конференции: в первый проходила консультация участников, во второй собственно защита проекта.

Консультация — одна из особенностей "Авангарда", добавляющая конференции образовательный момент. В начале дня к участнику "прикрепляется" консультант (как я понял, это в основном бывшие участники конференции, студенты профильных ВУЗов), который выслушивает доклад, задает вопросы и делает замечания в узких и спорных местах. С набором таких вопросов и замечаний участник отправляется на доработку своего доклада и презентации, а через некоторое время может показать их снова. В среднем каждый участник проходит через две-три такие итерации.

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

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

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

Балтийский научно-инженерный конкурс

Третья и последняя конференция, о которой я хотел бы рассказать, проходит в Санкт-Петербурге в начале февраля. Из этих конференций, Балтийская — самая крупная, и соревновательный момент в ней чувствуется наиболее сильно. Видимо, именно поэтому в ее названии нет слова "конференция", зато есть "конкурс" (и у нее есть статус Всероссийской олимпиады). Это действительно один большой конкурс, в котором практически полностью отсутствует элемент общения участников и обмена опытом.

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

Способ представления работ на "Балтике" — стендовый. Это значит, что, в отличие от школьной конференции и "Авангарда", не участники по очереди выходят со своей презентацией к экрану, а члены жюри ходят от стенда к стенду. Соответственно, участник должен рассказать о своем проекте каждому члену основного жюри, а также молодежному жюри, представителям организаций-спонсоров конкурса и просто всем интересующимся. Так что я могу посоветовать будущим участникам Балтийской конференции взять с собой на защиту пару литров питьевой воды, поскольку говорить придется много (по моим подсчетам, за несколько часов конференции я рассказал своей доклад более двадцати раз). Результатом был диплом лауреата в секции Computer Science и специальная премия Оргкомитета, чему я был весьма удивлен, так как сам не столь высоко оценивал свою работу.

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

И снова большое значение имеет подготовка презентационных материалов. В идеале лучше не поскупиться и заранее распечатать плакат на плоттере — тогда с ним будет меньше трудностей при закреплении на стенде. Текст должен быть напечатан достаточно крупно, так чтобы его можно было без усилий прочесть с расстояния в полтора метра (множество листочков формата А4 с мелким текстом, неряшливо наклеенных на стенд, едва ли можно назвать хорошим плакатом). Обязательно на плакате должны быть иллюстрации, привлекающие внимание, но при этом бессмысленное "украшательство" может скорее навредить, так как жюри в том числе оценивает как соответствие информации на плакате тексту доклада, так и полезность плаката для докладчика. Больше ссылок на плакат (вроде "вот, посмотрите на этот график") — больше баллов. Хорошо оформленный плакат заинтересует специалиста и заставит его подойти к вашему стенду раньше остальных, а значит, вы будете иметь дело с более лояльным и "не загруженным" членом жюри.

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

Итог

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

Материалы по проекту автора

Андриенко Матвей (10^В). Разработка стекового калькулятора с использованием виртуальной машины.

Презентация, Аудиозапись, Статья, Материалы

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

Основной компонент программы - это класс Interpreter, выполняющий код на языке стекового калькулятора, одну команду за другой. Некоторые инструкции языка позволяют <подменить> адрес текущей команды, что вызовет пропуск участка кода или его повторное исполнение, однако с точки зрения интерпретатора код остается линейным.

Все переменные, создаваемые пользователем, помещаются в оперативную память виртуальной машины, организованную по принципу стека. Стек - это структура данных, реализующая метод доступа к данным LIFO: первый сохраненный (push) в нее элемент будет извлечен (pop) последним. Такая концепция доступа к данным лучше всего <ложится> на принцип работы интерпретатора. Так как стек не позволяет получить доступ только к последнему сохраненному в нем элементу, а пользователю может потребоваться значение переменной, которая была создана ранее, был предусмотрен так называемые регистр: место промежуточного хранения переменных. Пользователь может <переложить> переменную из стека в регистр, а потом вернуть ее обратно.

Участок кода, начиная с некоторого адреса и заканчивая командой return, называется функцией. При вызове функции будет сохранен адрес возврата, то есть адрес команды, которая выполнится после функции. Все адреса возвратов также помещаются в стек. Если в коде встретится нескольких последовательных вызовов функций, последовательный переход по сохраненным адресам возвратов позволит <распутать> цепочку вызовов.

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

Важно отметить, что интерпретатор работает не с текстовыми названиями команд, такими как call, goto, sin и т.д., а с их числовыми кодами, так как сравнение чисел происходит гораздо быстрее, чем строк. Разумеется, разработчику было бы неудобно пользоваться такой системой команд, поэтому было разработано вспомогательное приложение - транслятор. Транслятор производит замену текстовых названий на их числовые коды, удаляет из кода лишние переносы строк и комментарии, подставляет фиктивный нулевой аргумент для команд, не требующих аргумента. Результат работы записывается в бинарный файл с расширением CALC.

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