Pull to refresh

Вся правда про Google Summer of Code — часть 4

Reading time 11 min
Views 7.8K
Часть 1
Часть 2
Часть 3

1. Как дожить до финального отчета (Final evaluation deadline)?

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



Во-вторых, именно на этом этапе могут обнаружиться ошибки проектирования, которые вы сделали в самом начале. Если раньше вы не видели (или сознательно опустили) возможности расширения функционала, то теперь как раз наступил этап «насаживания мяса на кости». И если эти кости окажутся неправильно спроектированы, то мясо вам повесить не удастся. Хорошо, если вам придется немного подправить архитектуру, ну или обойтись одним или двумя костылями, а вот если архитектура изначально была неправильна — то тут или резать функционал или все переделывать. Т.е. есть шанс провалиться на финальном отчете.

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

Как уйти в отпуск?

Большинство студентов уходят на небольшие каникулы после мидтерма. Некоторые во время отчетной недели. Но в отпуск ходят все, даже менторы.

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

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

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

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

2. Как пережить финальный отчет?

Когда у вас все хорошо и вы уже готовы подойти к финишу, вас могут ожидать небольшие сюрпризы. У вашего ментора может появится 1001 пожелание к коду, которые вы все должны выполнить. С вашей стороны вы, вроде, все хорошо сделали и уже готовы к финальному аккорду; со стороны вашего ментора — вы можете стать неуловимым Джо сразу после получения денег и фиг что потом доделаете. Поэтому, ваше сообщество будет стараться получить с вас код, который бы работал без дополнительной доработки. А поскольку у них пока есть разработчик, который этот самый код написал, они будут стараться довести разработку до конца, прежде чем вы получите деньги. Вот этим вы будете заниматься последние 2 недели. Вот поэтому на август ничего нельзя планировать — никогда не знаешь заранее о новых требованиях вашего ментора, он кстати тоже о них тогда еще не знал, а вот теперь его осенило.

Pencils down.

В западном мире «pencils down» означает «pencils down», т.е. вы ничего не коммитите после дня Х. В программе два deadline — мягкий и окончательный. После мягкого вы все еще можете коммитить и дописывать. Если честно, организации мягкий deadline не считают сроком окончания работы — «работать рабы, солнце еще высоко». Т.е. вполне вероятно, что после наступления мягкого deadline, ваша организация выдвинет вам еще один список требований. А вот окончательный срок сдачи — уже совсем окончательный. Официально Google не интересует код, который вы коммитите после дня Х. Т.е. отдать Google вы должны только тот код, который вы закоммитили до последнего deadline. И тут начинается маленькое западло — что делать, если ваш ментор соизволил протестировать код только на оценочном периоде, и вам нужно кое-что пофиксить. Тут нужно читать правила Google. Такой вопрос очень часто задают студенты, и, вроде бы, вы можете коммитить после deadline, но этот код в архив вы включать не должны. «Лишний» код вы опишите в файле README и скинете на него ссылку. Но я вам советую все доделать до начала оценочного периода и пнуть ментора потестить, дав ему ссылку на рекомендации Google.

Свой код вы отправляете только после того, как получили положительный результат на оценочном периоде. На создание архива вам дадут 2 или 3 недели. Чем раньше вы отправите код, тем скорее Google вышлет второй пакет.

Грязные хаки 3.

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

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

3. Свежая кровь.

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

4. Что еще пришлет мне добрый Google?

Футболку, картонку А4, что вы успешно завершили свой проект, и вроде бы все. Большие сообщества рассылают своим студентам дополнительные подарки — или после мидтерма или по окончанию работы. Что именно шлют сообщества — большой сюрприз, типа фишка такая.

5. Мифы.

Мы все равны:
Менталитет имеет значение. Все таки разная культура и разная система образования делают свое дело. Западные студенты менее закомплексованы, они больше задают вопросов и не боятся общаться.

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

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

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

Совмещать работу и GSoC невозможно:
Мой друг, решивший вспомнить молодость на последнем году аспирантуры, умудрился работая полный день успешно завершить GSoC. Еще он съездил в отпуск, сменил работу и переехал в другой город. Я не призываю заниматься таким мазохизмом, просто у каждого свой максимальный предел.

Все знают, что индусы дураки:
Стипендия, которую можно получить участвуя в программе, это довольно приличные деньги в Индии. Естественно, студенты из этой страны проявляют немалое рвение, чтобы попасть в программу. И соревноваться с ними очень сложно. Пока остальные студенты возмущаются из-за правила патча или любого другого кодинга, индусы по тихому коммитят. Когда они не проходят в программу — они коммитят. И когда через год они вновь подают завяку, их берут.
Да, их код не всегда красив и оптимален, но я не могу сказать, что лабораторные моих студентов похожи на работы профессионалов. А когда не видно разницы, зачем выпендриваться?

Главное кодить:
Иногда мне кажется, что главное трындеть. Чем больше вы трындите с сообществом и рассказываете, как вы мужественно кодили функцию из 100 строк или о том, как важен ваш проект для сообщества, тем больше оно «счастливо».
Как то один студен спросил сообщество, довольно ли оно его работой и пройдет ли он мидтерм. Один из менторов написал, что он доволен работой, т.к. прочитал в блоге студента, какие выгоды проект принесет сообществу. Правда потом добавил, что код он не смотрел.

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

Попасть в программу сложно:
Если следовать всем правилам сообщества с самого начала и отнестись серьезно к написанию пропозала (рано запостить, поработать с исходниками, общаться с менторами), то попасть в программу будет легко.

Попасть в программу легко:
Конкурс в непопулярном сообществе (т.е. вы о нем никогда не слышали и кодят они на непопулярном языке, например С или С++, или где нужны специфические знания математики) 3 — 4 человека на место. Количество заявок в популярное сообщество около 100, так что нужно очень сильно постараться, чтобы тебя заметили и выбрали среди 100 человек.

Мой ментор все знает:
Ваш ментор знает только ту часть проекта, над которой он работал. Безусловно, у него намного больше опыта, чем у вас, но даже он не владеет навыками телепатии. Т.е. когда вы будете говорить ему о своей проблеме, то скорее всего он или ничего не поймет или попросить описать все еще раз, но подробнее.

Сообщество знает что я делаю:
Если вы до программы работали только с учебными задачами и преподаватель заранее знал, где вы накосячите, то тут все не так. О том, что вы делаете, как вы делаете и какие проблемы могут у вас возникнуть, знаете только вы.

Если у меня проблемы, то знать о них должен только ментор:
Многие студенты ошибочно дистанцируются от сообщества. Однако такие вопросы как стиль кодирования, документация, тестирование, вопросы, связанные с запасным ментором, лучше решать со всем сообществом, а не с ментором.

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

Я один в поле воин:
Как ни странно вы не один, кто кодит в вашем сообществе. Пока вы кодите функцию A, которая дергает уже не вашу функцию B, кто-то эту функцию может переписать. Не забывайте про merging. Другие разработчики могут как пофиксить баги, так и создать новые.

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

2*2=4:
В Университете некоторые вещи вам объясняют как данность, не говоря почему так и может ли быть по-другому. Просто, большинство студентов не попадет в такие ситуации, где требуются расширенные знания. В GSoC вы можете столкнутся с тем, что ваше представление о «стандартах» не соответствует реальности.

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

Я работаю только с моим ментором:
Первое тестирование мой ментор сделал только на мидтерме (а может и не делал вообще), до этого он на код просто смотрел. До мидтерма тесты сделал другой ментор, он же нашел у меня пару багов.

Мой ментор — бюрократ, т.к. требует регулярные отчеты:
Менторы следят за студентами, а Google следит за сообществом. Если сообщество активно общается со студентами в рассылке или в чате, то в следующем году оно получит больше слотов. Так что «эти дурацкие отчеты» отчасти требования Google.

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

6. Из жизни.

Организация, в которой я участвовала в последний раз, малоизвестна и ведет разработку на языке С (который сейчас непопулярен среди студентов). Конкурс на участие был 3-4 человека на место и все кандидаты уже имели опыт разработки в этой области. У меня такого опыта не было, но похожую задачу я уже решала. Чтобы пройти по конкурсу, мне пришлось написать часть проекта уже на этапе пропозала. Менторы задали мне всего 2 вопроса — первый касался самого кода, второй — одного из этапов реализации. Никаких оживленных дискуссий до или после постинга не было. Более того, такой пропозал отпугнул других студентов от моего проекта.

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

На все мои письма мой ментор отвечал сразу же. Но когда я попросила протестировать его мой код, он исчез на неделю. У другого студента его ментор протестировал код только в середине мидтерма, хотя на все письма отвечал во время.

Одна из частей пропозала — короткое описание проекта. Это же описание становится паблик после вашего принятия в программу. Т.к. на пропозал я предложила код проекта, то на составление текста у меня было не так много времени — я просто скопировала описание идеи с сайта сообщества.

Т.к. у организации были очень строгие правила относительно стиля кода, то самые серьезные замечания я получила из-за пропущенных пробелов и магических чисел.

Объем кода, производимый студентом за GSoC это 2 — 5 тыс. строчек кода.

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

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

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

Все студенты обещают работать по 40 часов в неделю. В реальности рабочее время редко превышает 20 часов.

Все студенты делятся на два типа — одни любят правило патча, другие — ненавидят. Все организации делятся на два типа — одни хотят код в качестве пропозала, другие — конструктивный диалог.

7. Что почитать?

1. Рекомендации Google для студентов:
Не могу сказать, что я со всем согласна — многие аспекты работы зависят от сообщества и проекта. Но почитать эти рекомендации следует обязательно.

2. Рекомендации Google для менторов:
Читаем обязательно. Очень важно понять, как на вас смотрят ваши менторы и организации.

3. Очень известная статья русскоязычного ментора из gimp:
Много рекомендаций, как студентам так и менторам. Настоящий взгляд изнутри.

4. Инструкция по обращению с ментором:
Написана очень политкорректно. Для русскоязычного студента будет немного сложновато понять смысл данных советов. Но советы очень хорошие.

5. Откровения Google о том, как происходит раздел слотов:
Больше всего слотов получают организации, которые продолжают работать со старыми участниками GSoC, «крышуют» другие организации и успешно завершают проекты. Косвенно эти критерии могут повлиять на то, выберут вас или нет.

6. Выжимка из дискуссии о том, как не допустить исчезновения студентов:
Если прочитать очень внимательно, то станет ясно, что правила отбора кандидатов и их оценки с каждым годом будут все больше усложняться. Так что, тем, кому не нравится правило патча или кто любит все делать в последний день, следует задуматься, а могут ли они вообще участвовать.
Tags:
Hubs:
+44
Comments 11
Comments Comments 11

Articles