Цялата истина за Google Summer of Code
1. Как да оцелеем до междинния срок (краен срок за междинни оценки)?
В средата на лятото ще намерите много важен доклад за Google. Ако го преминете, ще получите парите си, ако не, ще излетите. Самият доклад е лесен – вие попълвате въпросник и вашият ментор попълва въпросник. Ако вашият ментор е доволен от вас, т.е. той попълни въпросника - тогава получавате желаните пари, ако не - тогава те се сбогуват с вас.
Основният критерий за преминаване на междинния семестр е да предоставите обещания код според вашата времева линия. Няма код, няма пари. Официално Google не се интересува какво точно и как го правите - основното е общността да е доволна. Ако общността е щастлива, значи и Google е щастлив. Така че, за да доживеете да видите доклада, трябва да направите общността щастлива.
За да поддържате общността щастлива -докладвайте редовно(запомнете думата „демокрация“). Ако никой не ви забранява да докладвате в пощенския списък, изпращайте доклади там. Ако блогвате, изпратете кратки отчети до пощенския списък с връзка към пълните отчети във вашия блог. Важно е общността също да види, че работите, а не само вашият ментор. Можете да забравите да посетите блога си, но всеки проверява пощата.
Чатете с други разработчици.Понякога най-голямата помощ, която можете да получите, не е от вашия ментор, а от друг член на общността. И така, един ученик имаше проблеми, които докладва в списъка с имейли. Неговият ментор отговори, че е разочарован от текущите резултати и не знае защо кодът hello world не работи. Но останалите разработчици са положили много усилия, за да се справят с проблема и да намерят решение. Менторът в края на темата ми позволи само да следвам съветите им.
Ангажирайте само чист код.Менторите много рядко преглеждат всеки ангажимент на студент. Обикновено тесамият факт, че има код и отчети, е достатъчен (обаче моят приятел някак си намери ментор, който провери всички ангажименти - но решихме, че това е биоробот). Но всичко това е до определено време. Случва се менторът да има свободен ден и най-накрая да реши да тества кода ви, а тази сутрин сте поели нощната си работа (да, най-фантастичният код се пише през нощта), който е просто безбожно бъги. И така, вместо да зарадвате обществото с вашите резултати, вие поставяте под въпрос цялата си работа. И ако това се случи преди прословутия междинен срок, когато наставникът е готов да ви оцени, това е двойно по-лошо. Така че създайте отделно кошче за себе си някъде и оставете късната закуска за работния код.
Ако имате някакви проблеми или пропуснете крайния си срок, тогава трябва да съобщите за това възможно най-скоро, за предпочитане в списъка с имейли, така че всички разработчици да ви се притекат на помощ. Вашият наставник и общността не очакват веднага да започнете да блестите и да се влачите от първите дни (не, те със сигурност се надяват, но напълно разбират, че това не се случва).
Ако сте написали графика си от глупости, веднага щом успеете да напишете жизнеспособен план, направете го и изпратете копие на наставника.Това ще го улесни да контролира напредъка на разработката. Най-често менторът задава точно този въпрос: „какво направихте според плана си и какво правите сега?“
2. Как да оцелеем в средата на семестра?
Две седмици преди началото на това събитие, попитайте своя ментор дали е доволен от работата ви и какъв резултат очаква до междинния срок.
Дори ако работите много добре и следвате ясно плана си, това не означава, че вашият ментор няма собствена представа за междинни резултати в главата си. Може би смята, че някоичаст определено ще работи и сте планирали тестването й едва след доклада. Разликата е като седмица - но в единия случай има работещ код, в другия няма. Телепатията е най-лошият метод за комуникация. Така че е по-добре да проверите всичко предварително. Седмица преди междинния срок определено трябва да знаете неговия отговор.
Ако не сте описвали много проекта си в пощенския списък, сега е моментът да го направите. Случва се в хода на разработката да няма какво да се описва, особено ако проектът е изследователски и сте прекарали целия месец в чукване само с една задача или кодиране на една малка, но много сложна функция. Ако по-рано във вашия отчет не сте имали с какво да се хвалите, сега можете да опишете всичко, което сте направили, да добавите резултати от тестове и описание на следващите стъпки за развитие. Запомнете - "демокрация", "щастлив".
Никога не въвеждайте мръсен код преди междинния семестр с надеждата да покажете докъде сте стигнали. Само след една или две седмици разработчиците ще започнат да се интересуват от вашите резултати. И няма да е много добре, ако вашата чернова версия постави цялата система плътно. По същата причина не пренебрегвайте тестовете - вашият код няма да бъде гледан, той ще бъде тестван.
3. Овърклок на проекти и отчети.
Някъде две-три седмици преди междинния срок проектът се ускорява. Тези. с всеки комит се добавя все повече и повече код и функционалност. Но вашето творение все още не е в състояние да премине нормални тестове, така че само вие виждате, че вече няма просто парче глина на масата, а кана.
За съжаление наставниците са лишени от дара на телепатията, така че не виждат вашата стомна. Виждат само, че глината се е увеличила и то значително. В такива моменти те изпадат в лека паника, от която излизат по два начина - сами анализират кода ви илипоиска да напише мега доклад. Анализът на кода е почти фантастичен сценарий, така че не го броя. Най-вероятно ще трябва да напишете мега доклад, от който ще зависи цялата ви по-нататъшна работа - или наставникът ще види вашата стомна, или ще докажете, че е там.
Разбира се, докладването прави вашата общност щастлива, но това е само началото. Тогава всеки иска да види страхотен работещ код и вашата задача е да му предоставите този код.
Но ако кодирате, кодирате и след това проведете тестовете и се окаже, че сте направили нещо малко погрешно там и много голяма част трябва да бъде финализирана или преработена. И точно тогава вашият ментор иска да погледне кода и да го тества. Добрият ученик ще си помисли, че не е добре един наставник да гледа това и да започне да пренаписва всичко, а умният ще се ангажира както е.
Първо, по някакъв начин вашият код все още работи и фактът, че преминава някои тестове, ви зарадва малко. Също така, тези резултати могат да зарадват вашия наставник, защото той ще види нещо работещо и ще повярва, че е на път да работи изобщо. Второ, целият ви проект се състои от произведения (имаше такъв предмет през 4-та година, но тогава някак не ни харесваше тази философия). Някои от тях са критични и трябва да се изпълняват последователно, а някои могат да бъдат изместени във времето. Когато установите, че нещо критично трябва да се преработи и отчетът е близо, тогава оставете работния код и се съсредоточете върху друга работа. Така ще преминете отчета и ще си освободите време да финализирате важна част след доклада. Трето, ако не го изтеглите и кодът ви не работи както трябва (или може би се справяте по-зле), тогава менторът може изобщо да не ви повярва. Е, откъде знае, че наистина работите, а не го лъжете? Затова се ангажирайте, но умно.
Други ученици ще работят с вас. С крайчеца на окото си погледнете напредъка им и се опитайте да не сте по-лоши от тях. Няма да направи ментор щастлив, че ученикът му е най-слабото звено. И не забравяйте, че не всички ученици са равни. Има студенти, които вече са част от общността и те могат да направят проучване поне за цялата програма, ако общността има нужда от това. Но това не означава, че можете да го направите.
Ако някой ученик има проблем и вие знаете как да го решите, защото вече сте се сблъсквали с нещо подобно, помогнете му. Първо, ще помогнете на човек, и второ, ще получите +1 към общителността.
Българският техникум обича телепатията. Ако във вашия университет ви е по-лесно да търсите в Google цяла нощ или да създадете тема във всички технически форуми на Runet, отколкото да се обърнете към учителя и да слушате какъв идиот сте, че сами не сте помислили за всичко, тогава това няма да работи тук. Попитайте вашия ментор, ако имате нужда от помощ. В крайна сметка те са отговорни за тези, които са опитомили.
4. Как да използвате ментор?
Като препратка към източника.
Фактът, че има конфликти, се признава от всички - и Google, и общността. Мисля, защото лятото на кодиране не се провежда през първата година, тогава механизмът за анализ на ситуации вече е разработен.
Ако имате: 1. Работен прототип 2. Правили сте редовни отчети 3. Започнахте да ангажирате код в края на май 4. Изпълнихте ли плана си
и вашият наставник все още не е доволен от вас, тогава трябва да се свържете с общността. Само защото вашият наставник не е доволен от вашето развитие, не означава, че и другите разработчици няма да харесат вашите резултати. Вероятно броят на хората "за" ще бъде повече от "против". Ако във вашата общност има човек, който отговаря за целия GSoC, тогава се свържете с него за разяснение относно вашето бъдеще. Ако общносттаАко сте глухи, тогава можете да се свържете с Google. Но как Google ще се държи, ако общността е недоволна, дори и не по вина на ученика, само Google знае. Самият Google казва, че е готов да предостави свой инженер, който да анализира тази ситуация. Тези. според вашето предложение, график и код, той определя кой е прав - общността или вие. И това решение е окончателно. Въпреки че мисля, че тази ситуация, когато имате работещ код и сте спазили всички правила, и всички са недоволни от вас, е по-скоро фантастична, отколкото реална.
Ако следвате указанията на Google за студенти, трябва да се сбогувате с ученик, ако: 1. Междинният срок няма обещания код 2. Ученикът не е много общителен и е трудно да се работи с него по-нататък 3. Няма пълна сигурност, че ученикът ще завърши проекта 4. Студентът не успява да оправдае очакванията на общността
6. Неуспешни проекти.
Успешният проект е три балансирани параметъра: време, бюджет, ресурси. С бюджета и ресурсите тук всичко е ясно, има срокове, в които студентите просто не се вписват. Най-честите неуспешни проекти са:
b) Проекти, които изискват проектиране на сложна архитектура или API на ранен етап.Как започва всичко?Студентите правят една версия, след което на някакъв етап от разработката осъзнават, че тя трябва да бъде изоставена. Кодът се пренаписва изцяло и така два-три пъти. Тук няма нищо необичайно - нормален процес на разработка, не всеки може веднага да намери идеално решение, което ще бъде разширимо. Малко опит.Какво трябва да направя?Започнете разработката възможно най-рано, за да има време за връщане назад. Е, опитайте се внимателно да обмислите всичките си архитектурни решения, преди да ги приложите. Не забравяйте да се консултирате с ментори в трудни ситуации, особено когатовреме за кодиране и все още няма работеща версия.
c) Проекти, в които целта за развитие не е ясно зададена от самата общност.Например, ако идеята на вашия проект първоначално е описана в стила на „има такъв непознат боклук и ние искаме същото, но ние самите не знаем какво е“, тогава е възможно на някакъв етап от развитието да разберете, че правите нещо малко по-различно от това, което се очаква от вас.Как започва всичко?След стартиране на проекта, когато кодът вече е започнал да преминава първите тестове, студентът внезапно открива, че резултатите трябва да са малко по-различни. След това започва подробен анализ на проекта и предложение.Какво да направите?Пишете подробни доклади всяка седмица, за предпочитане още през май, когато едва започвате да се справяте с проблема. Или улавяте всички недоразумения в ранните етапи на развитие, или трябва да преразгледате полезността на вашето развитие за общността точно преди междинния срок.
Но зависи от опита на общността. Начинът, по който се държаха предишните ученици, оставя незаличим отпечатък в съзнанието на наставниците. Има "млади" общности, които участват за първи или втори път. Все още не са се натъкнали на мързеливи ученици, така че могат да ви повярват докрай.
По време на програмата често възникват непредвидени ситуации. Разболявате се, или имате семейни проблеми, или сте претърпели сериозна катастрофа — каквото и да е, започвате да пропускате крайните срокове. Разбира се, можете да се договорите с наставника за забавяне или някои смени, но всички ваши споразумения се отменят в средата на семестра. Тоест или има код за междусрочен срок, или го няма. Получавате заплата за свършената работа, а ако работата е много по-малка от договорената, няма да ви бъде заплатена. Всичко е просто и без обиди: пари сутрин - столове вечер, пари вечер - столове сутрин.
Защо организациинеуспешни проекти?
Нищо, но се случи. Или общността участва отскоро и все още не знае как да работи с учениците, не знае на какво са способни, или менторите преценяват сами - „Можех да го направя на неговата възраст. “(не е фактът, че може, но те очакват нещо подобно). Може също така да се окаже, че общността не е имала провалени проекти и е във възход, т.е. увеличава трудността, докато учениците плъзгат. Но този път беше - добре, не го влачиха. Или някой наставник имаше луда идея в главата си, тя беше добавена към списъка за разнообразие и след това се намери ученик. Разбира се, организацията отговаря за списъка с идеи и изглежда гарантира, че всяка идея може да бъде реализирана за три месеца, но вие също имате глава на раменете си и тя може да мисли. Ако се съмнявате - не се захващайте с проекта, може би ще има друг ученик, който определено ще ви влече.
Hardcore conf в C++. Каним само професионалисти.