Итоги GSOC20.09.2016 08:18

30 августа закончился Google Summer of Code, в котором мы принимали участие во второй раз. В целом результат достойный — большинство студентов подтвердили, что их выбрали не зря. Но были и ошибки, о которых расскажем в этой статье. Для подведения итогов GSOC были опрошены менторы — те самые люди, на плечах которых всё и держалось последние полгода. Подробности под катом.

Напомним, что весной были отобраны пять проектов:
1. GUI-based FTP client — создание FTP-клиента с графическим интерфейсом, исправление ошибок в реализации протокола и добавление поддержки некоторых команд протокола FTP, поддержка докачки файлов, протоколирование истории действий.
2. Torrent client — создание (написание обёрток для библиотек одного из кроссплатформенных клиентов) консольной версии клиента, который будет выполнять скачивание (декодирование файла, получение списка пиров, установление соединения с пирами), раздачу, обработку сообщений от трекера и показ статистики.
3. Port PolarSSL — порт библиотеки на язык ассемблер, в том числе написание криптографических алгоритмов и поддержка протокола TLS.
4. CPUID_tool — обновление программы, чтобы она могла идентифицировать процессоры, выпущенные в последние 9 лет, а также определять размеры кэшей и поддерживаемые функции.
5. C layer — написание обёрток на языке С для библиотек box_lib, proc_lib, libini, libio, http, rasterworks, kmenu, libimg, libgfx, archive, buf2d, xml, libcrash.

Подробная информация о проектах представлена в таблице.

Отзыв ashmew2:

Я был ментором в проекте FTPC.
Текущий статус проекта — графический интерфейс и реализованы основные функции.
Я добивался следующих вещей, руководя студентом:
 — объяснить ему, что нужно часто делать обновления и писать сообщения на форуме;
 — (очень важно) заставить взять его на себя ответственность за проект и считать его своим продуктом;
 — быть только маяком, указующим путь и не пытаться кормить студента с ложечки;
 — давать достаточно альтернативных вариантов и оспаривать его подход (подсказывать только, если это необходимо);
 — еженедельные обсуждения (2 раза в неделю, исходя из свободного времени студента).
В итоге, для меня это был хороший опыт руководства и обучения кого-то, как работать над проектом.
Самое лучшее с моей точки зрения то, что даже после GSoC студент всё еще улучшает FTPC и я продолжу им руководить так долго, как он пожелает, потому что это и есть прелесть открытого кода (Open source)!

Отзыв dunkaist:

Строго говоря, я не был официальным ментором на этом проекте, т.к. недавно сменил работу и объективно не мог уделять достаточно времени GSoC. Студентом занимался другой человек. Тем не менее, когда Utsav решил дорабатывать мою заготовку торрент-клиента (на тот момент, фактически, парсер torrent файла и основные структуры и константы), я согласился по возможности помогать ему и отвечать на вопросы. Поначалу они были, однако довольно быстро прекратились. Спустя некоторое время я сам стал интересоваться текущим положением дел, и оно меня не порадовало. Коммиты также были редкими и малосодержательными. Отсутствие вопросов при такой активности настораживало, хотя студенту неоднократно давали понять, что любые вопросы можно и нужно задавать хоть на форуме, хоть в IRC и не смущаться. Невпечатляющие успехи к промежуточной аттестации я списал на длительное вхождение в проект. Примерно на двух третях программы я выделил вечер, чтобы как следует разобраться с текущим положением дел. И обнаружил, что некоторые мои советы и существенные архитектурные решения проигнорированы. Что, вообще говоря, не плохо при наличии разумной альтернативы, которой, однако, я не обнаружил. 24 августа, по окончании этапа разработки, код из репозитория даже не собирался. Позже сборка была пофикшена и студент выкладывал скриншоты с рабочим кейсом, который у меня так и не заработал. Если Utsav продолжит развивать этот проект, я готов мёржить его код и исправлять архитектуру, чтобы сохранить разработчика, в противном случае продолжу с того места, где однажды закончил. Поживём — увидим.

На работу над проектом претендовали три студента, но по стечению обстоятельств пришлось выбрать студентку из США. Не думал, что в США всё так плохо с образованием. Выбранная студентка оказалась довольно слабой и ленивой, старающейся отложить сложные части проекта на потом. Также она постоянно врала, что почти всё сделала, а через неделю или две оказывалось, что почти всё сделать и только начать для неё одно и то же, а в ответ на замечания о плохой работе даже хамила. В основном она занималась копипастом с последующей небольшой модификацией кода. В итоге к середине лета было сделано около четверти проекта при полном отсутствии понимания как общей картины, так и деталей процесса идентификации процессора. Перед мидтермом я предупредил других менторов, что шансы на реализацию новых алгоритмов равны нулю. После получения незаслуженных денег по инициативе администратора Pathoswithin, темп работы вообще упал, она начала править внесенные ей же баги и улучшать интерфейс вместо написания новых функций. К первой декаде августа было сделано меньше половины проекта и где-то в это время выяснилось, что студентка так и не прочитала полностью документацию Intel и не знала, что надо писать новый код для функции 04H. Когда я ей это пояснил, то она отказалась и вместо написания кода предложила написать документ о том, как это сделать (sic!). После этого она начала делать довольно легкое задание — написание исключения. Сделала две попытки, в обоих случаях программа падала при запуске на новых процессорах… Закономерным итогом стал фейл проекта — ну нельзя ставить pass за недоделанную программу, которая падает при запуске. Но история продолжилась… Об этом ниже в разделе ошибок.

Для операционной системы, большая часть которой написана на ассемблере, этот язык как никакой другой подходит для разработки системного программного обеспечения. Это связано с удобством вызова системных функций, простотой организации структур данных, возможностью эффективного использования ресурсов компьютера, красотой применяемых решений и, наконец, с определённой увлекающей олдскульностью. Однако программирование на ассемблере требует больше труда, чем на языке высокого уровня. Так уж повелось, что для KolibriOS приличное количество приложений написано на C. С другой стороны, за последние несколько лет на языке ассемблера были реализованы библиотеки функций, упрощающие жизнь программистов. Идея проекта C_Layer заключалась в реализации интерфейса этих библиотек для программ, написанных на языке C. Это, в свою очередь, позволило бы унифицировать часть кода (т.е. в идеале свести к минимуму использование программистами своих «велосипедов»), упростить и ускорить процесс разработки, а также уменьшить количество багов в новом коде. C_Layer должен был обеспечить повсеместное использование стандартных элементов графического пользовательского интерфейса, которые реализованы в библиотеке box_lib. А это и «эдитбоксы», и «чекбоксы»… В общем, почти всё, что нужно. Так же в планах были интерфейсы к библиотекам для работы с графикой (libimg, libgfx, buf2d, rasterworks), файлами (libini, libio, archive, xml), сетью (http). Студент punk_joker, который работал над проектом, по мнению ментора (Albom), выполнил необходимый для успешной сдачи минимум, хотя ожидания были значительно большие. Итак, что же было сделано? Написаны интерфейсы на языках ассемблера и C для основных библиотек, примеры на C и «мэйкфайлы» для сборки интерфейсов и примеров. Чего не хватало — так это документации и тестов. Но малый размер примеров позволит программистам досконально их изучить и понять принципы использования интерфейсов. Насчёт организации работы студента тоже всё было неоднозначно. Punk_joker потерял много времени, разбираясь в вопросах самостоятельно, не прося помощи у ментора и игнорируя его рекомендации. В итоге, много работы пришлось выполнять в последние дни GSoC. Тем не менее, на сегодня проект находится на нормальном уровне (как для выполненного студентом), работа над ним не прекращается и, надеюсь, будет развиваться и приносить пользу сообществу программистов KolibriOS и открытому программному обеспечению в целом.

Мнение dunkaist:

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

Начинается всё с заявки на участие, в которой студент обнаруживает своё незнакомство с такой сущностью, как архитектура проекта. Большинство заявок похожи как две капли воды и сводятся к реализации 10% от намеченного, затем ещё 10% и так постепенно до 100%. О правиле 80/20 мало кто слышал. Для студента непонимание архитектуры проекта выливается в неграмотный план, по которому нельзя работать и, как следствие, потере ориентиров. Для ментора это головная боль с выставлением оценки, если какой-то код написан, но критическая масса для рабочего прототипа не набрана.

Второе, чего часто не понимают студенты, — требования и ожидания со стороны сообщества. Для многих студентов $5500 до выплаты налогов за три месяца — большие деньги, и потому они ошибочно воспринимают GSoC в качестве работы. Причём, в самой примитивной её форме: я тебе деньги — ты мне код. Такие вещи как диалог с участниками проекта или открытое обсуждение исчезающе редки. Менторы представляются начальниками, которым нельзя задавать глупые вопросы, а сообщество кучкой злобных тестеров, которые только и ждут повода понасмехаться над ошибками новичка. Для студента такое непонимание порождает затянувшееся вхождение в проект и потерю времени; для ментора — дополнительные преграды при выявлении проблем и попытках помощи.

Не всё гладко и у самих менторов. Бытует мнение, будто задача ментора — отвечать на вопросы студента. Я лично убеждён, что это не так и что истинная задача ментора — организовать процесс. Процесс, при котором студент напишет код. Это ежедневная задача, которая отнимает время и которую нужно держать в голове. Отвечая на вопросы студента, ментор лишь очищает свою совесть: я давал ему всё, о чём он просил. На практике же студент молод и неопытен и может не задать правильных вопросов, ошибиться в выборе направления разработки. Для студента это тупик в архитектуре, возникший через недели работы, срыв сроков и результирующий fail. Для сообщества — очередной брошеный проект, минус один потенциальный разработчик.

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

Я считаю, что важны не только профессиональные, но и человеческие качества участников процесса. И поэтому нужен очень тщательный отбор всех участников GSOC — администраторов, менторов, студентов Тенденцией этого года было наличие аферистов как среди студентов, так и среди администраторов в нашем Open Source проекте. И обоим типам нужны только деньги. Аферисты-студенты всячески тянут с выполнением проектов, на любые уговоры они реагируют небольшой активностью чисто для галочки. Их бы устроило даже 500 долларов за месяц community bonding, а если им еще и на мидтерме дать денег, то они вообще наглеют и перестают работать, что и случилось с моей студенткой. Более того, когда её сфейлили, то она стала разыгрывать удивление, писать в поддержку GSOC и на форуме о том, какая у неё сложная жизнь и что она набрала кредитов после того, как её приняли в GSOC. Другой неприятной новостью этого лета стал Pathoswithin, чьи действия, на мой взгляд, говорят о том, что он аферист. Он вызвался стать администратором, хотя был в проекте около полугода, потом он стал писать, что возьмет часть денег себе, потом стало ясно, что эта часть будет довольно большой. При этом он практически ничего не делал и допустил ошибку на мидтерме, когда сам решил заполнить за всех менторов отзывы и пропустил мою студентку-аферистку. Когда стало известно о его ошибке, то он стал перекладывать вину на меня, создавать на форуме и в чате разнообразные скандалы, чтобы отвлечь внимание от своих планов по присвоению денег GSOC.

Комментарии (0)