Журнал «Компьютерра» №39 от 25 октября 2005 года - Компьютерра. Страница 31
Далее надо было выяснять, являюсь ли я студентом. Студентами Google считал всех, кто обучается в каком-либо официальном учреждении. В частности, было прямо написано, что аспиранты (PhD students) могут участвовать в программе.
Остальные вопросы обсуждались в google groups " summer-discuss". В той же рассылке можно найти предварительную статистику по странам. Похоже, принадлежность определялась по домену почты, так что данные вряд ли точны. Но на 13 июня было подано 1695 заявок из США, 372 из России (2-е место), 147 с Украины (9-е место).
Прежде чем перейти к моему проекту, расскажу, чем я вообще занимаюсь. Многие приложения по большей части состоит из работы с деревьями. В компиляторах это преобразование одних деревьев в другие, в текстовых процессорах — обработка структуры документа. Хотя приложения совсем разные, набор базовых операций над деревьями совершенно одинаковый. Столкнувшись с тем, что мне приходится писать по сути один и тот же код для разных окружений, я подумал, что с помощью XML-технологий мог бы решить эту проблему. Кроме того, мне не нравилось, что кода на такую задачу в принципе требуется слишком много — а вот если бы я использовал XML-технологии, то достаточно было бы написать тривиальные XPath-выражения.
Так почему же не использовать XML-технологии для любых древовидных данных? На мой взгляд, единственное препятствие — отсутствие библиотек, которые могут адаптироваться в зависимости от программного окружения. Эту проблему я взялся решать[" Reusing XML processing code in non-XML applications"] с помощью виртуальной XML-машины, байт-кодом которой является язык Scheme, а за основу универсальной реализации XPath/XSLT/XQuery были взяты библиотеки проекта SSaX.
Несколько пилотных проектов показали, что идея жизнеспособна. В качестве финального теста я решил немного модифицировать XSLT-процессор xsltproc, а именно заменить движок XPath на мою версию. После чего можно сравнить результат исполнения сложной XSLT-программы (например, преобразования DocBook) в обоих вариантах и сделать вывод о пригодности универсального кода.
В процессе работы я заметил, что «выход в Scheme» значительно расширяет возможности XSLT и позволяет писать более сложные по функциональности, но более простые в поддержке преобразования. Анонс SoC послужил катализатором. Я записал мысли, оформил их как идею проекта «XSieve: XSLT + Scheme, альтернатива XSLT 2.0» и отослал заявку.
По моей оценке, шансов было мало, а времени до даты ответа хватало, поэтому я подзабыл про SoC. Тем приятнее было получить письмо от Google с поздравлениями. А через пару дней в пустом до этого ящике оказалось более сотни писем. Оказывается, был создан закрытый список рассылки, который наполнился обменом радостями и описаниями проектов, выяснением, кто из какой страны и университета, и вопросами, как связаться с ментором и что делать дальше.
Формальности по работе над проектами зависели от ментора. Где-то достаточно было использовать систему контроля версий, а в некоторых проектах крупных организаций надо было строго следовать инструкциям и письменно подтвердить, что автор выпускает свой код под нужной open source лицензией.
Так как я работал над своим собственным проектом, то мой ментор (Йосики Хаяси [Yoshiki Hayashi] из Google) свел формальности к минимуму. Он попросил выложить проект на SourceForge и подробно описать язык XSieve. Но на всякий случай я посылал еженедельный отчет о проделанной работе.
Большой проблемой оказались бумажные формальности. Надо было по факсу отправить в Google следующее: некое подобие договора; свидетельство о том, что участник является студентом; форму W-8BEN для бухгалтерии Google и реквизиты банковского счета, куда переводить деньги. Для подтверждения своего статуса я отксерил аспирантское удостоверение и сам перевел фразы на английский язык. Неопытного человека могло бы затруднить открытие счета и указание реквизитов. Но тут в качестве помощи можно использовать форумы и FAQ русских шареварщиков. Единственным камнем преткновения оказалось заполнение формы W-8BEN, а точнее поля ввода ITIN.
ITIN расшифровывается как Individual Taxpayer Identification Number, его российским аналогом является ИНН. Нет ITIN? 30% (1350 долларов) идет дяде Сэму в лице мистера Буша. Есть ITIN? Тогда как повезет, это зависит от договоренностей между странами. С Россией договор есть, так что до нас в итоге должна дойти вся сумма (-13% налога).
Участники имеют полное право называть программу (по крайней мере, первый месяц) «Summer of Taxes». Благодаря рассылке, мы узнали много нового о налогах в разных странах, а также о получении ITIN. Единого мнения о том, как это делать, так и не сложилось. Я в заявке на ITIN указал «Nonresident alien required to obtain ITIN to claim tax treaty benefit», «Exception 1» и treary article number для «Personal Services». К заявке приложил документ от Google, в котором они должны были бы объяснить, зачем нам нужен ITIN. По-моему, у них это не получилось, поэтому я дополнительно написал cover letter. Последняя необходимая бумажка — сертифицированная копия загранпаспорта. Пришлось идти в американское консульство и оставить там $30. Понравилось, что нотариус работает в часы для приема американских граждан, поэтому очереди не было. Не понравилось, что тетушка стала докапываться до деталей, зачем мне нужна копия. Я не был готов к вопросам, но ответил без проблем.
Но это только начало. Многие из нас еще не получили ITIN, а устроители программы не готовы ждать. Поэтому Google удержит с нас 30% и переведет их IRS (налоговикам). После получения ITIN мы можем требовать у IRS эту суммы обратно. Будет такой Winter of Taxes.
И снова возвращаюсь к проекту. Долго не мог за него взяться. Вначале был на конференции, потом в деловой поездке, а потом пришлось разгребать последствия апгрейда и трехнедельного отсутствия. Все это время ментор кормился рассказами о том, что, благодаря накопленному запасу кода, проект удастся завершить в срок. Так, к счастью, и вышло.
Работу над проектом я разбил на два этапа:
XSieve собирается и устанавливается как любая другая GNU-программа, с помощью configure, make, make install.
DocBook XSL stylesheets, преобразованные в XSieve, работают правильно (суровый тест).
Я ожидал, что на первую задачу уйдет много времени и, к сожалению, не ошибся. Хитросплетения autoconf, automake, libtool и прочих autotools оказались сложны для понимания. На самом-то деле, там все тривиально, если понять принципы построения системы. Но на это у меня ушло больше недели. XSieve достаточно сложен в плане зависимостей, для него нужны специальные версии Guile и xsltproc, а сам XSieve собирается как плагин для xsltproc. Необходимые настройки были разбросаны по разным make-файлам. После перевода системы сборки на autotools все значительно упростилось — и для конечного пользователя, и для разработчика.
Вторую веху я планировал пройти за полторы недели до конца SoC. Однако для ее достижения потребовалось выполнить несколько второстепенных задач, так что тест удалось запустить только за неделю до сдачи. Естественно, он провалился. Хуже того, XSieve вел себя совершенно непредсказуемо. Через несколько дней исследований выяснилось, что загвоздка — в сборщике мусора Guile. Тут я запаниковал и стал думать о том, как сообщить ментору о провале проекта, ибо такие проблемы с памятью быстро не лечатся. К счастью, медитация над документацией и здравый смысл подсказали, где подправить, чтобы сборщик мусора не хватал лишнего.
Дальше — дело техники. Хоть багов и поднакопилось, все они были легко воспроизводимы, и поэтому их удалось быстро локализовать и исправить. Последняя ошибка была закрыта в последнюю ночь. Финальную версию я обозвал XSieve 1.0.0 и выложил на SourceForge.