« март 2009 | Main | май 2009 »
Пейзаж отчасти напоминает район боевых действий: безлюдные, с выбитыми стеклами, дома — сносят, строят новые; ночью — прожектора, так и ждешь объявления воздушной тревоги; воронки, как от снарядов — больше года уже все сплошь раскопано, ремонтируют теплотрассу. В дождь, или вот — пока таяло всё — грязь непролазная, когда подсохнет — тучи пыли. Стаи собак. Коптево, словом.
Ну, я понимаю, при советской власти это считалось бы — в порядке вещей; но теперь-то уж я и забыл, как такое бывает.
Тьфу.
Posted at 01:26 AM | Permalink | Comments (1)
Tempora mutantur et nos mutantur in illis
Ныне, кстати, tempora mutantur еще быстрее, чем в эпоху Овидия, и для нас, грешных, это означает, что требования к программам, которые мы разрабатываем, меняются быстрее, чем мы успеваем их разработать. Можно, конечно, спорить — хорошо это или плохо, но что это — реальность, с которой приходится считаться — думаю, не вызывает сомнений.
На практике сие означает, что в написанный код приходится вносить изменения уже в процессе его разработки, а затем — еще и в процессе сопровождения. А потому грамотный, с моей точки зрения, код должен — помимо прочего — обладать таким качеством, которое я бы назвал модификабельностью.
Однако, интуитивно, мне кажется, понятно — о чем, собсссно, речь. Можно, поэтому, наверно, и сформулировать некоторые критерии модификабельности кода — без претензии на всеохватность — и, соотвественно, некоторые рекомендации.
Первое (и главное): код должен создаваться как модификабельный изначально. Разрабатывая его, будем помнить, что когда-нибудь кто-нибудь будет его переписывать. И важно, что сегодня мы даже в страшном сне не можем увидеть, как именно («аксиома неопределенности»). При этом, вполне возможно, что переписывать-то будем мы сами — когда начисто забудем, что и почему мы там понатыкали, а времени на то, чтобы вспомнить, у нас будет ровно до утра — когда назначена презентация продукта потенциальным инвесторам.
Второе: код должен быть структурирован в соответствии со структурой алгоритма. Мысль довольно туманная, но важная. К тому же она поддается некоторой (косвенной) конкретизации — соберем в одном месте все фрагменты, решающие одну локальную задачу, а которые разные — разнесем: желательно по отдельным модулям. Если используется константа (хрестоматийный пример), пусть единожды — определим ее в шапке соответствующего фрагмента: не будем забывать, что нам не дано предугадать не только, как наше слово отзовется, но и во скольких неожиданных местах отзовется оно, когда нам придется всё переписывать (см. «аксиому неопределенности» выше).
То же касается и законченных операций — соберем их в процедуру или функцию с подходящим названием — и вызовем; пусть это даже необходимо один раз: во-первых см. «аксиому неопределенности», а во-вторых это же — нагляднее, поскольку явно именует то, что мы делаем.
Помимо того, что это удобно чисто технически — важно еще и
Третье: чтобы код был ясным. Что означает — незапутанным и понятным. Проникнемся мыслью, что текст на любом языке программирования нужен-то человеку, а не машине, и будем проще, и там, где можно выбрать между «красотой» и ясностью — выберем ясность.
Дело это тоже, конечно, с трудом поддается формализации — что ясно одному, может быть совершенно неясно другому; но, к счастью, и здесь возможно предложить некоторую конкретизацию: в идеале код попросту должен читаться, как более-менее связный текст на английском. Были, конечно, на заре развития советской вычислительной техники ассемблеры с инструкциями типа «идти», «взять», или «переслать», однако случилось так, что именно английский ныне признан в качестве международного стандарта. Что теперь поделать; да и хорошо, что, например, не китайский — представьте язык программирования, основанный на иероглифах? представили?
Итак — ясность и еще раз — ясность. А уж остальное — дело оптимизатора, а не кодировщика и тем более — не программиста: задача последнего — придумать оптимальный алгоритм; путать это умение с умением сэкономить на двух присваиваниях, выполняемых каждый високосный год — есть, вообще-то, признак дилетантизма.
Ну и — комментарии; да, банально, я понимаю; я поэтому подумал-подумал и не стал выделять их в отдельный раздел. С другой стороны, комменарии комментариям — рознь: уж лучше никаких комметариев, чем
if(a>0) // :-) *_* (-: праверим что а менше 0 :-) *_* (-:Четвертое: код должен быть переносимым — «портабельным». В идеале — должен без потери качества идти на любой платформе, где есть соответствующая стандартам поддержка языка, на котором он написан.
Здесь я, наверно, задену чувства многих, кто считает, что настоящий «крутой программер» — знает все особенности регистровой пересылки в железе, с которым работает, и основывает на этом знании свою работу, а все остальные — суть ламеры.
Кхм... Господа! Использование сведений о деталях машинной реализации для написания кода, или — тем более — создания алгоритма — признак, некоторым образом, непрофессионализма. Профессионал — ясно это понимает и использует исключительно в тех случаях, когда обойтись без знания реализации нельзя уж никак — причем делает это с крайней неохотой, выделяя такой машинно-зависимый код в отдельный модуль.
(Здесь сразу хочу заметить, что хорошо всем известные средства автоматического конфигурирования отношения к сказанному не имеют ровно никакого — поскольку сам код при их использовании может быть переносимым, а может и не быть. Это скорее средства обойти проблему, чем ее решить; при этом их собственного качества с точки зрения, о которой я пишу, даже и не будем касаться.)
Профессиональный программист — и об этом писалось давно и многократно — вообще не обязан (а лучше всего — не должен иметь возможности) знать, как его программа будет исполняться — просто потому, что это будет побуждать его концентрироваться на ее сути, а не на множестве мелких деталей — получая более общее, а значит, в среднем, более надежное решение (об этом см. также здесь). Беда только, что ныне это, продиктованное здравым смыслом, положение совершенно забылось, и лишь это мешает осознать всю массу проблем, возникших в результате.
С другой стороны, можно, конечно, сказать и так: «выброшу старый код совсем и напишу новый с 0» — однако, более крупных программных единиц всё сказанное касается в еще большей степени — например, замена любого программного модуля модернизированным, приводящая к необходимость переписывать заново все остальные, — еще менее желательна.
Словом, будем помнить, что все меняется, не будем рассчитывать, что пишем на века. Будем скромнее.
Posted at 04:40 AM | Permalink | Comments (0)
Стало быть, продолжаем разговор.
В предыдущей заметке я писал о программке для хранения паролей, которую можно носить с собой, скажем, на флешке. Однако флешка тоже не всегда случается под рукой: ну, как-то не предполагали вы, что окажетесь там, где неожиданно оказались: сюрприз это был для вас, да и всё тут.
И вообразите — для решения проблем таких вот непосед (вроде меня) есть онлайновые сервисы, берущиеся хранить ваши секреты прямо в Сети; ну, чтоп два раза не ходить. Можно, конечно, спорить по поводу полезности и/или безопасности такого решения; отдавать чужому дяде ключи от своих заветных сундуков — вроде и боязно: даже если дядя и чистейшей души человек — вдруг кто-нибудь другой, не столь честный — слямзит?
И, в общем, хранить подобным способом коды доступа к вашему банковскому счету я бы все же не рекомендовал — равно, как и ключи к шифрам и телефоны агентурной сети: если вы, к примеру, секретный агент иностранной державы, или, тем более, тайный ваххабит. Но в то же время прочую-то, не столь критическую информацию держать таким образом мне кажется очень удобным — при условии, конечно, что поставщик сей услуги способен гарантировать ее надежность.
Я в свое время выбрал для этой цели сервис Clipperz.com, итальянский, как я понимаю. И вот почему.
Сервис бесплатный — более того: open source, под лицензией AGPL — существует уже несколько лет и пока, вроде бы, довольно активно развивается. Полностью построен на известных, сертифицированных криптоалгоритмах, что обеспечивает некоторую уверенность в его надежности. (Здесь для тех, кто полагает, что надежность защиты тем выше, чем меньше о ней известно, нужно, наверно, пояснить, что это отчасти справедливо только пока из компании не уволен ни один разгильдяй или склочник — после чего вся «секретность» накрывается медным тазом; а достаточную степень надежности может обеспечить только подходящий математический аппарат — при грамотной реализации.)
Регистрация в сервисе анонимная — а значит, простая: логин-пароль, никаких e-mailов. Ну, мастер-пароль («passphrase»), понятно, следут выбирать надежный, «123» явно не годится; для помощи в этом, конечно же, есть индикатор его стойкости. Забывать пароль нельзя — доступа к нему нет ни у кого (для входа используется SRP), и, следовательно, его восстановление невозможно.
Можно хранить неограниченное число логинов-паролей и, вообще, самой разной регистрационной информации в виде «карточек» (при создании можно выбрать нечто вроде шаблона): имена, телефоны, веб-адреса, номера кредитных карт итд. Есть «direct login» — очень удобная и надежно работающая функция автоматического входа на любой ваш ресурс со своими аутентификационными данными — т.е. «в один клик» — и есть «букмарклет» (тьфу, прости господи) автоматически собирающий необходимые для этого данные. Есть компактная версия списка ваших карточек для загрузки в боковую панель Firefox или Opera. Одноразовые пароли — для входа с чужой машины. Возможность на своей собственной машине сохранить локальную (оффлайновую) копию ваших данных, защищенных так же, как и в сетевой. Есть, наконец, импорт данных (в т.ч. из KeePass) и экспорт. (См. картинки, англ.) Многоязычная поддержка есть (например, китайский), но русского — увы, нет. Желающие могут и помочь, наверно, с локализацией.
В общем, с некоторой осторожностью — рекомендую. Use case, естественное дело, мало чем отличается от уже описанного ранее:
Пока готовил это заметку, нашел еще один подобный сервис: Passpack.com — с некоторыми достоинствами — например, возможностью входить с OpenID или логином Google — но, как мне кажется, беднее функционально. Пока им не пользовался.
Ну, до связи. Дальше собираюсь еще немного порассуждать о методологии программирования. Оставайтесь с нами.
Posted at 07:18 AM | Permalink | Comments (0)
Начинаю делиться своим «избранным» со средств хранения аутентификационных данных. Паролей, проще говоря.
Здесь, думаю, любителям везде использовать один пароль «123», или «qwerty», считающим, что никаких особых ценностей у них нет и что поэтому всякие такие спецсредства им без интереса, следует рассказать вот о чем. Оно, конечно — фотографии вашей кошки и записки «как я провел лето» никому, кроме вас, особенно не нужны и красть их никто, скажем, не будет. Но вот распространять спам, или диффамацию, или, неровен час, призывы к насилию от вашего, заметьте, имени — можно запросто. А в правилах пользования большинством ваших сервисов вписана строчка о том, что за сохранность своего пароля каждый пользователь отвечает самостоятельно — как и за произведенные от его имени действия. Отвечает не перед администрацией сервиса. А перед судом. И в случае распространения, например, упомянутых уже призывов это может быть крайне неприятно.
Ну вот. С другой стороны — есть, конечно, деятели, которые держат в памяти по три сотни паролей и могут уверенно их вопроизвести, будучи разбужены в 7 утра 1 января. Но я к таким не отношусь, поэтому использую замечательную программульку под названием KeePass.
Бесплатная (open source, OSI sertified), компактная, с морды симпатичная. Состоит, фактически, из одного ехешника. Есть версия на PortableApps — для работы с флешки — но зачем она есть, непонятно, поскольку всё замечательно работает и просто так, само. База защищается мастер-паролем или ключевым файлом (впрочем последнее использовать я бы не рекомендовал); Twofish, или AES/Rijndael, 256 бит. Настраиваемая система рубрикации записей (жаль, тегов нет), поиск, сортировка. Очень хороший генератор паролей, в т.ч. по маске; с индикацией стойкости. Средства автозаполнения, которые, впрочем, в реальных условиях работают не слишком хорошо, поскольку просто генерируют клавиатурные коды. Два метода защиты от перехвата клавиатуры. Поддерживаются плаги, один из которых позволяет импортировать пароли из Firefox, что, согласитесь, удобно.
Итак, use case:
Ну, ладно, закругляюсь. Заболтался я тут.
Продолжение следует. Оставайтесь с нами.
Posted at 11:34 PM | Permalink | Comments (0)
Нам электричество пахать и сеять будет...
Помню, еще в юности, встретился мне в какой-то книжке заголовок: «Уравнение думает за нас» — не помню у кого, у Гарднера, кажется, а может, и нет. Смысл дальнейшего рассуждения сводился к тому, что решение грамотно составленного уравнения способно давать результаты — в том числе побочные — которых мы при составлении вовсе и не ожидали. Что, в сущности, совершенно верно.
Ну я прочитал все это — не очень внимательно — да и забыл; но в душу все же запало — тем более, что мой школьный учитель физики Михмас, и наставник Коля Шершнев (каждый заслуживает отдельного рассказа) постарались задолбить мне эту идею по самую шляпку. Однако подлинная ее ценность стала мне ясна только гораздо позже: в ходе приобретения горького опыта программирования.
В самом деле: код, который мы пишем, в конечном счете есть — если кто забыл — ничто иное, как некое математическое выражение (мне уже приходилось упоминать это вскользь, см. здесь), офигенно сложная функция, преобразующая дикое множество входных значений и параметров (в широком смысле этого слова, включающем, например, команды пользователя) в жуткое множество выходных. И будучи составленным по-настоящему грамотно, код способен давать очень важный практический эффект — быть адекватным даже в тех условиях, которых мы при его разработке и не предусматривали. Вести себя, как взрослый. Думать сам.
Мне лень сейчас искать практические примеры (возможно, прицеплю позже) — важен принцип. Вернее, для меня — их три.
Первый: алгоритм решения задачи должен быть представим математически. Хотя бы в общих чертах. (Вспомним, что логика, или, тем более, комбинаторика — разделы математики). В процессе математического формулирования часто становятся видны такие особенности предполагаемого решения, или самой задачи, которые вовсе не видны при неформальном подходе.
Второй: алгоритм должен быть простым. Точнее — его сложность должна соответствовать сложности самой задачи, но никак не превышать ее. Если решение простой на вид задачи по мере разработки становится все сложнее — стоит задуматься: правильно ли понята и описана задача? подходящий ли алгоритм выбран для ее решения?
Третий (тесно связан с двумя предыдущими): задача должна решаться выбранным алгоритмом полностью, без «лакун», заполняемых отдельно. В этом, на самом-то деле и состоит «элегантность» решения. Что означает отсутствие в нем т.наз. «special cases». Ну, ладно — пусть не совсем отсутствие. Но хотя бы минимум. Ситуацию, когда на один случай «штатной» обработки приходится дюжина «special cases», спасает лишь одно средство — корзина для мусора. И возврат — даже не к выбору алгоритма, а — к постановке задачи.
На этом, последнем, стоит задержаться. Сказанная ситуация часто возникает из-за лени и/или недостатка времени. Когда выбранный алгоритм, вчерне реализованный в виде кода, впоследствии приходится «обвешивать» заплатками, поскольку при его выборе реальные условия работы не были учтены — а, говоря по-умному, множество входных данных неожиданно оказалось шире того, что предполагалось изначально. Будемте, друзья, с самого начала реалистами, или уж в крайнем случае — пессимистами.
В сущности, все это — не откровение. И написано много где. Но когда я заглядываю в исходники... В общем, давайте будем следовать принципам — хоть каким-нибудь. И код у нас всегда будет мягким и шелковистым. И будет нам счастье.
Код — он не устает, не бывает болен или раздражен — вот пусть за нас и думает. У него это явно получится лучше.
Вот только — как бы еще научится его такой писать...
Posted at 05:03 AM | Permalink | Comments (0)
Что мне нужно от мобильного телефона? Чтобы с его помощью я мог связаться, с кем мне нужно, из любого места, где я нахожусь (не будем уточнять, где именно). Всё.
В самом деле, больше от мобильного телефона, мне не нужно ровным счетом ничего. Почему? Попросту потому, что такая возможность — связь — бывает жизненно необходима, а обеспечить ее каким-то другим образом невозможно — телепатия слишком ненадежна, а любое другое техническое устройство, рещающее эту задачу, функционально будет — тем же мобильным телефоном.
Вот вам и современный мобильник — в котором все это есть. Однако нюансы возникают и тут. Во-первых, я готов платить за то, чтобы в нем было все, что мне нужно, но совершенно не готов — за то, что мне не нужно и нужно не будет никогда. Нет, если за ту же цену — пожалуйста, я не против: но так, чтобы это не усложняло пользование — повсеместное наличие в меню неубираемого пункта «игры» меня просто бесит. Я бы вообще хотел, чтоп всё, что мне необходимо, вызывалось одним нажатием. А если у меня на борту 18 вариантов каких-нибудь органайзеров — это, по правде сказать, невозможно.
Ну, мысль, я думаю, ясна (тем более, что не нова): с собой я бы хотел иметь некое устройство, которое делало то, что мне нужно и было легко управляемо — а значит, не содержало ничего лишнего. Т. е. для этого оно должно быть — легко конфигурируемым, причем даже не обязательно мной, а скажем, продавцом, или хотя бы изготовителем, который мог бы поставлять различные его модификации для разных групп потребителей.
Вот. И то же самое, в сущности, мне нужно от софта, с которым я работаю. Любого, включая операционную систему. Да, собственно, в первую очередь — операционную систему — чем же еще определяется удобство моей работы и, главное, возможности, которыми я располагаю.
Что мне нужно от нее? Возможность запускать задачи, желательно, параллельно — чтоп железо не разленилось — управлять ими, получать результаты их работы в доступном виде и сохранять где-нибудь — вдруг после понадобятся. Вообще-то всё.
Но ведь дальше начинаются нюансы. А бороться с ними — прямо у себя, потребителя, дома, да с учетом того, что компьютер — штука по идее весьма универсальная и гибкая — вроде бы должно быть легко и просто.
Однако, хороши ли с точки зрения, изложенной выше, форточки от научно-производственного объединения «Microsoft»? Нет. Почему? Да потому, что рыночная конкуренция по принципу «кто в лес, кто по дрова» превратила их — совокупно с морем написанного под них софта — в подобие биоценоза с многообразием организмов, борющихся за существование и ресурсы, отращивая каждый свои собственные органы для выполнения одних и тех же функций — которые к тому же зачастую дублируют функции самой ОС: попросту потому, что последние — скажем осторожно — не вполне хороши. И ужас как хочется порою губы Никанора Ивановича да приставить к носу Ивана Кузьмича, но никак нельзя-с — поскольку программный интерфейс между указанными товарищами не предусмотрен, а только может быть приобретен отдельно: всего лишь за какие-нибудь $999.99.
В Linux (и прочих потомках Unix) дело бы обстояло намного лучше, поскольку от родителя он унаследовал принцип повторного использования компонент и заложенный на базовом уровне интерфейс для этого. Обстояло бы. Но не обстоит. Поскольку всё было прекрасно, когда набор этих самых компонент исчерпывался базовыми подсистемами и парой десятков утилит; теперь же ситуация качественно изменилась — ведь среднему программеру (а не среднему, кстати — и подавно) проще написать все с 0, чем разбираться в том, что написано до него. И в результате ситуация медленно дрейфует в ту же сторону, что уже описана выше — показывая пример дивергенции в полуживой природе. При этом набор доступного софта для Linux все-таки еще и значительно меньше, чем для Windows — являющего глазу решительный Базар на Деве; к тому же софт для Linux естественным образом имеет некоторую хакерскую ориентацию — что, как следствие, делает сборку прибора, годного простому смертному для повседневных нужд, делом также весьма нетривиальным. (Только не говорите мне про всякие OpenOfficы, которые недурны, хотя и съедают ресурсов на порядок больше традиционно не склонных к аскезе продуктов Microsoft — однако же не одними офисами жив человек, а повседневными мелкими шпуньками, которые бывают незаметны, но без которых — никуда.)
Прочие гордые имена, похоже, навечно вписаны на гранитные плиты в мавзолее отрасли — забудем о них.
(О художественных произведениях Apple не говорю, поскольку рассчитаны они — при всем уважении к дивной их красоте — на то, чтобы под капот к ним никто не лез; а мне как раз большую часть своей трудовой биографии под ним-то и пришлось коротать)
Ну, вот. Совершенства, как и положено — нет. Сижу я (и кропаю этот текст), естественно, под Windows — просто потому, что за многие годы набрал себе все — и редакторы, и средства разработки, и утилиты. И что, собственно, еще нужно? Да и привык, собственно — даром, что когда-то Windows характеризовали в советской литературе, как «графическую оболочку, громоздкую и малополезную».
Но помечтать-то...
А вам?
Posted at 09:29 AM | Permalink | Comments (0)
Белый орел подружился с белой вороной.
Оказалось — есть о чем поговорить. По вечерам, при ясной луне, сидели на кухне, пили чай. Делились впечатлениями.
Обменивались также опытом. У белой вороны-то жизнь, конечно, разнообразнее была, чем у орла: в кругах, где тот вращался, расцветкам такого уж значения не придавали, да и высокого полета он птица: поди разбери издали — белый он там, или какой. Впрочем, если все ж разбирали — смотрели тоже косо. Но пальцем не показывали.
Не то — у вороны. Всякая сволочь в приличном сером своем офисном прикиде норовила пальцем ткнуть — что это за цаца такая, во всем белом? чистенькой больно, что ли, хочет быть? Ну и случаев разных могла она привести без счета, и дать множество практических советов — как при таком оригинальном обстоятельстве приобретать друзей и оказывать влияние на окружающих. Орел — с достоинством прихлебывая чай — слушал задумчиво, не перебивал; мотал на клюв.
Правду сказать, их особенности-то, обоих, белизны-то — под всякими житейскими наслоениями было уж вовсе и не видно невооруженным глазом. Так что, по большей части, и не замечал их уже никто: так, встречаются какие-то ничем не примечательные старички, чай пьют — ничего особенного, только что-то дичатся больно.
И сказок, разумеется, никто про них не сложил: как, например, про того же бычка — со всеми, конечно, минусами его профессии и общественного положения.
Так я подумал, может, хоть сам попробую.
Posted at 09:56 AM | Permalink | Comments (0)
Время от времени (почти каждый день) я обращаю внимание (машинально бросаю взгляд) на статистику посещений моей литературной странички в Мошковском "Самиздате". Ее теперь можно смело назвать мемориальной, поскольку по причине большой занятости (и некоторого отупения) давно уже ничего я туда не выкладывал.
"Звездой" и местом паломничества миллионов она вообще-то никогда не была, а теперь даже и времена, когда в месяц заглядывало туда человек двести-триста, также давно прошли. Однако, при том, что цифры, которые там можно наблюдать, вполне могут уложиться в пределы статистической погрешности, общая картина довольно для меня занятна.
"Четыре", в общем зачете долгое время безусловно лидировавшие (поскольку попали еще в несколько каталогов), ныне потеснил "Карр", рекомендованный мною же самим "для знакомства" — поскольку стилизация (которой я вообще люблю развлекаться) под фентези показалась мне на тот момент самой гуманной из того, что я могу предложить случайному читателю, озадаченному, что за хрень тут, у этого афтара понаписана.
"Сказка заката", поначалу никем не замеченная, а затем, в начале прошлого года, поднявшаяся на первую позицию, снова вернулась туда, откуда поднялась. Несмотря на то, что также "рекомендована". И ниже нее только "Время воздаяния", которое никуда не поднималось, а сидит на своем месте тихонько с самого начала.
С ним я провел эксперимент: разбил на две части, а позже еще опубликовал послесловие (поначалу не собирался). Чтобы оценить, какой процент на самом деле прочитает до конца. Оказалось — типа, один из трех; причем послесловие читают чаще, чем окончание — видимо, по странной привычке забегать вперед: чем закончилось-то? Учитывая, что вторая половина разительным образом отличается от первой, а послесловие вообще повествует о самых отдаленных исторических и литературных ассоциациях, связанных у меня с этим текстом, и читателя, еще его не прочитавшего, способно только запутать — следует, вероятно, признать этот эксперимент не очень-то удачным.
А фсе патамучта многа букоф; относительно, конечно — для "Самиздата". Почти все немногочисленные комментарии, полученные мною там, содержат мысль, что, дескать, до конца не дочитал, но очень нравится (вар.: "неплохо, неплохо"). Родные, я обычно заканчиваю совсем не то, не так и не тем, чем начинал (иначе писать скучно), так что вам, возможно, и не понравилось бы — дочитайте вы все же до конца. Судя по разбросу оценок, скажем, "Четырех" — от "очень хорошо" до яростного "не читать!" — так, вероятно, с некоторыми и происходило. (Впрочем, это я не в укор; читать все до конца я бы и сам, наверно, не стал.)
Неожиданной популярностью стали пользоваться "Стихи и птицы" — сборник стихотворений 70-80-х гг., в марте покрывший вообще все остальное с большим отрывом. Ну, просто потому, что первый в списке. Следом за ним (тоже, в марте) — "Восход голубого": вероятно, из-за названия; мне даже пришлось предпослать ему разъяснение, что составляющие его тексты были написаны во времена, когда слово "голубой" обозначало цвет.
Но такая, вдруг проснувшаяся тяга народа к поэзии несколько озадачивает. Впрочем, наверно — просто весна.
Posted at 12:46 AM | Permalink | Comments (0)
Recent Comments