Для тех, кто вяжет

1. Общая теория написания статей (выдержки).

Чужого не возьмешь — своего не будет
(пословица)

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

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

Почему я начал с общих слов о написании статей? Мне (как и всем, кто не любит телевизор и радио) приходится много читать. Чем взрослее я становлюсь, тем больше мне приходится читать тексты, написанные близкими мне по возрасту людьми. В этом вступлении я пытаюсь выразить свои пожелания к окружающим меня текстам. Может быть, когда я перечитаю эту рукопись, я учту изложенные в ее начале пожелания, а само начало выброшу. И рукопись станет лучше.

Далее приведены опытным путем полученные эвристики, изложенные в виде советов (с комментариями).

1. Не нужно писать лишнего.

2. Если использовать в тексте фамилию знакомого человека, это станет для него дополнительным стимулом прочитать текст. Например, я уже создал такой стимул для четырех человек. Не всякий текст может этим похвастаться. Такой прием позволяет отсеять неугодных читателей (фамилии которых не были использованы) и сократить объем критики. Например, могу предположить, что круг читателей книги "Кто есть кто на Среднем Урале" почти исключительно состоит из упомянутых в ней фамилий. Исключение из данного правила представляет собой "Энциклопедия великих физиков".

3. Сюжет повествования должен развиваться настолько быстро, насколько это возможно. Конечно, желательно сохранить связность между соседними предложениями. Но читатель должен понять, что он — на коротком поводке, и если он хоть через что-нибудь перескочит, ему придется несколько раз перечитать три предыдущих абзаца, чтобы понять в чем дело.

4. Интерес к тексту повышается, если читатель ощущает себя немножко умнее автора. Важно не переборщить, и можно даже иногда щелкнуть читателя по носу (не думай, что ты один такой умный!). Более подробно. Читатель должен радоваться, что фраза (шутка, теорема, вывод) понятна ему не только из-за того, что он знает русский язык, но и в силу обладания им иных познаний. Приведу пример. Не так давно один юморист с экрана телевизора пошутил, что если выпить водки "Чайковский", то в голове начинает звучать "Щелкунчик". Обратите внимание, что в шутке водка не используется совершенно. Сравните: если выпить газированный напиток "Ромео", перед глазами возникает Джульетта. Газированный напиток ни к чему. Исправим первую фразу так: если вечером хорошенько попить водки "Чайковский", то утром в голове та-акой "Щелкунчик"!. Здесь слушателю уже интереснее, если он, конечно знает, что после хорошей водки самый щелкунчик в голове — утром. Я где-то читал, что это называется использованием металингвистического контекста. Но заумные слова часто отталкивают зрителя — потенциального собеседника.

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

2. Какую задачу решать первой?

Проблема выбора погубила не одного осла.
(пословица)

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

Второе возражение в том, что задача, кажущаяся поначалу простой, может содержать подковырки (Никита Шамгунов ввел термин "катышки"). В результате, эта задача может "съесть" чересчур много времени.

Общая идея такова. Начинайте решать задачу, для решения которой — вы точно знаете — вам НИЧЕГО больше не надо. А именно, ничего из приведенного далее списка:

а. вывода формул; б. громоздких тестов; в. обоснования алгоритма решения и скорости его работы;

Иными словами, это должна быть наиболее типовая задача, которую следует вбивать "назубок". Так в "Что? Где? Когда?" игроки дают досрочный ответ, будучи уверены в успехе. Как только один из членов команды говорит, что готов сесть и вбить задачу — пусть садится и вбивает. Единственное условие — ответственность. Задача должна быть вбита и сдана быстро. Как научиться быстро выбирать такие задачи? Ответ прост. Надо прорешать большое количество типовых задач. Задач на "волну", на "бек-трекинг", алгоритмы на графах, потоки в сетях, обработку текста, последовательности, и т.п. Только тогда вы сможете с уверенностью отличить простоту. Очень важный момент — чтение ограничений. Мал золотник — да дорог! Если не заметить ограничения — это все. Лучше прочитайте задачу на три раза.

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

Нет ничего страшного, если более легкая задача оказалась прописана на листочке раньше, чем готова первая на компьютере. Можно и нужно прерваться, чтобы дать возможность товарищу отличиться. Это время не пропадет даром — напишите тесты к своему решению, помогите третьему. "Невидимый труд" стократно окупится, когда свою последнюю задачу вы начнете решать на полчаса (даже на 20 минут!) раньше. Классическим примером кажется Ульм этого года. Среди задач имелась одна простая, которую многие команды сдавали начиная уже с 9-ой минуты. Будущие же чемпионы, судя по всему, даже еще не дочитали до нее, так как нашли и сели вбивать типовую задачу. Когда же (минут через 20-30 после начала тура) задача была обнаружена (неизвестно, с помощью ли "монитора", или прочли, наконец, условия), они прервались и сдали ее на сороковой (!) минуте. В первых рядах сразу они не оказались, и даже не очень спешили со второй задачей (видимо, занимались и третьей). Но уже начиная с третьей решенной задачи это окупилось. Чемпионам Ульма — Ура!

3. Сверим часы!

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

"Золотой" норматив: 40/60. Взяв "типовую" задачу, и получив компьютер, один человек должен получить "Accepted" за 40 минут. Более сложную задачу этот один человек должен решать за 60 минут, причем из них время t1 — на листочке, а потом t2 — на компьютере. t1 + t2 = 60, t2 не превосходит 30 минут. К листочку возвращаться нельзя.

"Обычный" норматив: 60/80, где t2 не превышает 45 минут.

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

В целом, команда должна стремиться сдать первую задачу в пределах 30-40 минут, вторую и третью — с шагом в 35-45 минут. Далее о времени, по всей видимости, не имеет смысла говорить — куда более важными становятся иные факторы.

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

1. Вы получите удовольствие от новых знаний, пусть и не в области программирования. С эрудированным человеком часто интереснее общаться и вы не замедлите почувствовать это на себе.

2. Вы приобретете опыт работы программистом, который пригодится вам везде, а не только на олимпиаде. Жизнь шире!

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

4. Гораздо чаще, чем вы думаете, может оказаться, что вы знаете (точно!) как решать самую сложную задачу — неплохой бонус!

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

4. Рука руку моет.

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

— приличная скорость набора текста программы (хотя бы 75-80 знаков в минуту);

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

— элементы математической культуры — понятие труднообъяснимое;

— умение объяснить свои действия и свой алгоритм коллегам;

— знание основных структур данных — определений, свойств.

Каждый обладает всеми этими качествами в той или иной степени. Список приведен не затем, чтобы вы поглядели на него и сказали "А! Я все это умею, и никому это не надо!". Список нужен затем, чтобы вы, решив очередную задачу, задали себе вопросы: — достаточно ли быстро я набрал программу? — не слишком ли медленно отлаживал? — Как можно было сделать это быстрее? — Было ли более элегантное математическое решение? — В чем изюминка моего алгоритма именно для этой задачи? — Нет ли элегантного решения задачи через необычную структуру данных?

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

Итак, цель списка — указать на необходимость постоянного самосовершенствования, в том числе на тренировках. Иначе — привет. Это не моя мысль — как только человек поверил, что он достиг потолка хоть в чем-то, он тут же с этого потолка и падает.

Вторая составляющая команды — взаимопомощь. Не знаю, как можно (и можно ли) ей научить. Здесь, как в футболе, играет каждый, но все друг друга страхуют. Наверное, для хорошей коммуникабельности (модное слово, правда?) необходимо верить партнеру больше, чем себе. Если у него не отлаживается — бросать свои формулы и садиться за тесты для него. Или даже за отладчик. Или за распечатку. Лично мне кажется, что чистая совесть перед партнером важнее любой победы. Чувство вины перед другом, если ты подвел его, перевешивает радость забитого мяча или выигранной подачи.

5. Соревнования как работа.

Одно из правил, развивающих психологическую устойчивость в экстремальных ситуациях соревнований — отношение к ним как к работе. Твое дело — решить 6 задач вместе с друзьями. Хорошо сделал свою работу (быстро, без ошибок) — получил зарплату. Плохо сделал — ищи другую работу. Неверно думать, что главное отличие в том, что работу можно сделать на следующий день, а повторить выступление в соревнованиях — только через год. Норвежские лыжники, выигрывающие олимпиады, редко прекращают свои тренировки и выступления (если вообще прекращают). Выступил на олимпиаде — готовься к чемпионату мира. А там много этапов. Какой-то этап пройти не удалось — найдутся показательные турниры, еще что-нибудь. Праздничная эстафета, наконец. То же про теннис. Программистам памятен 1995 год (особенно две последние цифры). В этот год Евгений Кафельников не выиграл Уимблдон. Ну, не вышло. Ну и что? Он сел и стал ждать Кубок Кремля? Ничуть не бывало — уехал выступать на открытое первенство Швейцарии.

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

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

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

Очень здорово, что у нас на факультете проводится целенаправленная политика более равномерного распределения соревнований по всему году.

Есть еще один аспект в отношении к соревнованиям как к работе. Это грамотная и осознанная именно работа над задачами. Поясню на примере с бриджем, в который я когда-то играл. Суть дела такова. Есть два партнера, у каждого из них по тринадцать карт. Они стремятся определить наилучшего козыря, но переговариваться можно только на специальном языке. В результате точный расклад описать удается крайне редко и приходится прибегать к интегральным характеристикам расклада. Например, считаем туз за 4 очка, короля за 3, даму за 2, валета за 1 (это называется шкалой Милтона Уорка) и сообщаем партнеру сумму очков по своим 13 картам. Ясно, что партнер может сделать некоторые выводы из этой информации. Однако часто выводы не могут быть однозначны, и в процессе "диалога" партнеры стремятся информацию уточнить. Каждый из них в результате имеет некоторое "дерево вывода", исходя из которого и принимает решение. В результате, после окончания игры часто можно слушать переговоры наподобие: "а я думал, что у тебя... а если бы у тебя было... а ведь могло получиться, что ...". Если каждый из партнеров рассуждал честно, обычно они довольны результатом, независимо от его высокости. А вот если кто-то поленился, то ему достанется. Пример диалога: — а если в следующий раз у тебя будет не три короля а два, что мне тогда делать? — а вот тогда ты будешь кидать мне карты через стол и страшным голосом кричать "Учить считать!"

Приведенная фраза принадлежит моему партнеру по бриджу, К.Щеколдину. Но она относится не только к бриджу. Тренируясь совместно (сюда входит и учеба вместе, и работа, и чтение одних книжек, и много чего еще, а не только замеры по 5 часов!) вы вырабатываете свою технологию решения задач, свои методы программирования, на которые вправе рассчитывать ваши партнеры. Если партнер написал для вас ввод данных в структуру, а ваш алгоритм потом неверно ее обработал, причем ошибка не в алгоритме, а в том, что вы неверно поняли устройство структуры данных — вряд ли партнер будет вами доволен. Общение между вами в предшествующий период жизни как раз и служило тому, чтобы вы вещи, которые называете одинаково, и понимали одинаково.

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

6. Краткая идеология решения задач.

Эта (к сожалению, достаточно банальная) глава встречается во всех руководствах, учебниках и учебных курсах по программированию. Не хотелось на ней останавливаться. Делаю это только для того, чтобы прояснить извечный вопрос "Нужно ли программировать классы?". Две основные точки зрения таковы. Первая. Классы (объекты) на соревнованиях программировать не нужно, т.к. на их разработку уходит больше времени, чем на реализацию через регулярные структуры данных и глобальные переменные или функции. Объекты необходимы в реальной жизни, так как упрощают процесс восприятия программы по прошествии значительных промежутков времени после ее написания, упрощают отладку, в том числе, отладку сложных систем. На олимпиаде же, где внутренний мир задачи достаточно узок, структура программы достаточно прозрачна, и глобальные переменные не привносят в жизнь проблему зацепляемости модулей, вполне можно без этих самых объектов обойтись.

Иная точка зрения заключается в применении классов всюду, вне зависимости от конкретной задачи. Ее сторонники приводят такие доводы. Существуют люди (и их больше, чем вы думаете) которые способны за рекордно короткий срок минут эдак в 35 набрать программу размером 5-6 килобайт, не поддающуюся отладке. Существует немало примеров, когда и на соревнованиях глобальные переменные причиняли людям немало беспокойства. Если программа написана через классы И (!) ваш партнер тоже привык воспринимать мир через призму объектов, ему легче помочь вам с отладкой и доделкой программы. Наконец, есть много людей, просто получающих удовольствие от написания программ, где есть свой маленький мир, а в нем — свои герои.

Лично мне вопрос использования классов не кажется столь важным. Важно, чтобы вы были предсказуемы для партнера, чтобы ему было легко с вами работать. Если вы привыкли каждый день жить в мире классов, если у вас получается, то какой смысл меняться в тот самый момент, когда на вас смотрят судьи — никакого. Обратно, если вы твердо уверены в своей правоте, что классы не нужны на соревнованиях, никто не вправе вас заставить писать объекты. Лишь бы получалось. Есть хорошая поговорка, гласящая, что у человека только тогда что-то получается, когда ему нравится этим заниматься.

7. Оценка сложности перебора.

Помимо сложностей, которые испытывают участники соревнований, решая предложенные задачи, существуют еще и сложности, которые испытывает программный комитет любого подобного конкурса, подбирая эти задачи. Директор Европейского региона Tom Verhoeff написал на эту тему замечательную статью. Рассмотрим вкратце эти проблемы.

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

Если задачи не будут оригинальными, их будет не интересно решать. Рассмотрим способы, выделяющие, чем именно бывают оригинальны задачи. (Часть способов взята из уже упоминавшейся статьи, автор — Tom Verhoeff).

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

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

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

Г. Задачи из редкой предметной области. Программисты часто ограничены в остальных областях человеческого знания (как зачастую и составители задач). В том числе, даже и в приложениях собственной области. Не потому, что они столь уж ленивы — просто области приложений огромны. Это позволяет давать на конкурсы задачи из сравнительно редких предметных областей (попытку такого рода можно усмотреть в задачах про сохранение свойств капсул и про сети Петри на финале 1998 года), считая вероятность того, что задача кому-либо хорошо известна, достаточно слабой.

Размышления над предложенными оригинальностями могут помочь определить сложность перебора (но НЕ метод решения). А именно: если вам кажется, что задача решается известным алгоритмом, дайте себе 3-5 минутный труд доказать это. А именно, доказать, что задача решается этим алгоритмом В предложенных ограничениях. Если ПКК постарался, то выбор алгоритма без такого доказательства (кроме случаев, когда вы — компьютерный гуру, и для решения всех задач вам достаточно спинного мозга, а голова не обязательна — близкая к тексту цитата из К.Щеколдина) приведет к тому, что решение работать не будет.

Обратно, не спешите отбрасывать идею о полном переборе. Не так уж редки случаи, когда ПКК ошибался. Если вы сумеете (опять же!) доказать, что полный перебор укладывается в отведенное время, почему бы на этом не заработать? Нет причин.

8. Чему можно научиться на испанском сервере.

Существует чудесное место, где можно набить руку в сдаче задач по программированию. Это сервер acm.gui.uva.es в Испании, университет города Valladolid.

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

Никто не ограничивает вас пятью часами или иными временными рамками. Можно сдавать сколько угодно — был бы Интернет. Вы можете скачать себе все формулировки задач оптом и далее выбирать задачи по своему вкусу: на обработку текста, на последовательности, на графы, на что угодно.

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

9. What You can't learn at 5-hours long trainings.

An apple every day keeps the doctor away.
English proverb.

Of course I suppose that reader is able to read English (that's why I called him READer). Otherwise he will not understand the contest problems.

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

Итак, помимо тренировок — чтение книг (всех интересных книг, которые только встретятся на вашем пути!), встречи с интересными вам людьми, решение задач в уме по дороге в университет. Стремитесь видеть задачи всюду — и вы увидите их. Конечно, не следует строить из себя параноика, кричать о найденных задачах и своем оригинальном образе мышления на каждом углу. Между подготовками (такие периоды ОБЯЗАТЕЛЬНЫ! чтобы не сойти с ума) нужно жить чем-то другим. Но полтора месяца перед туром — это отдельная жизнь, и прожить ее нужно так, чтобы "потом не было больно за бесцельно прожитые полтора месяца".

Автор: Евгений Штыков, аспирант УрГУ