PaulTaykalo · July 3, 2018 05:58
diff --git a/Intro.txt b/Intro.txt
 Так. немного информации для тех, кто сюда недавно попал
 1) ICFP Contest - ежегодное соревнование приуроченное функциональному программированию
 2) Несмотря на то, что оно приурочено и связано с конференцией по функциональному программированию, можно участвовать на любых языках программирования.
 3) 72 часа без берерывов и выходных
 4) Каждый год задание разное и разной степени интересности и сложности.  Задания прошлых годов легко гуглятся. Лучшим заданием IMHO есть задание 2006 года http://users.livejournal.com/-adept-/24049.html . 
 5) Это немного не олимпиадного вида контекст. Но тут зависит от задания
 6) Язык - Kotlin :slightly_smiling_face: В этом году мы пишем на котлине. Близкоскриптовый, компилируемый, надо меньшче писать чем в джаве, поддерживает всю джаву из коробки
 7) Другие языки. В прошлом году мы попали на кейс, когда серверная часть писалась на другом языке, и часть команды, которая ее писала отвалилась после первого дня. (В принципе предупреждали, что так может быть, и люди делавшие эту часть потом ее суппортили, за что им отдельные кудос, но факт есть факт - мы недооценили важность такого момента).
 8) Remote vs onsite. *Onsite* лучче. Итерации очень быстрые и очень легко выбиться из контекста. А ко вторым 24 часам все будут очень раздраженные и никто не захочет по 5 раз обьяснять все :slightly_smiling_face:
 9) В виду того, что часто есть много аспектов задачи, приветствуются и настоятельно рекомендуются сообщения вида "Я сделал Х, его можно запускать Y, с параметрами Z *отключить* вот тут если вдруг что"
 10) На реализацию всего что приходит в голову времени нету. и(смотри 7й пункт) deal with it.
 11) Кривой, быстро работающий алгоритм *намного* лучше чем "правильно-сделанный-и-архитектурно-правильно-true-100%-clean-coded". 72 часа, особо не разгонишься. Особенно если это не критичная кусок кода.
 Пример. Мы для получения пересечения площади полигонов просто скармливали полигоны в CoreGraphics(аналог) рисовали их и считали пиксели. Реузльтат легко заменям, несложен для понимания, и занял пару 10 минут.
 12) Тесты маст хэв. Особенно те, которые покрывают спецификацию. Используемые стуктуры данных имеют свойство меняться достаточно быстро, и без тестов - мы будем сидеть в бесконечном дебаге. Благо это не swift, и тут все быстрее происходит. Почти во всех заданиях была некоторая виртуальная машина, либо формат данных, которого надо придерживаться, и как оказалось можно делать по 10 весьма тупых ошибок на одну строчку кода. Так что там, где есть спецификация - там должны быть тесты.
 Я не говорю про TDD, но тесты данные на вход-данные на выход нужны 
 https://github.com/stanfy/icfpc2016/tree/master/src/test/kotlin/icfp16
 https://github.com/PaulTaykalo/icfp-2017/blob/master/src/test/kotlin/org/icfp2017/GameTest.kt
 13) По результатам предыдущих ICFP. Есть высока вероятность что после очередного брифинга, вы осознаете, что вы ничего не поняли, и вы не знаете за что браться. Это норма. Поймите, где вы лучше всего можете помочь, и закройте эту брешь. Не помогло? - дерните кого-нить и спросите чем можно помочь :wink: Лучше, конечно. быть проактивным. но иногда после потери контекста это сложно.
 14) Если задач меньше чем людей (маловероятно, но бывает) - то pair programming all the things.
 15) Ежечасовые 'hourly'(обсуждение статуса) в первые 24 часа. Дальше - По договоренности. 
 16) Атмосфера. В условиях ограниченного времени и места, тон общения весьма накаляется, и возможно вы будете готовы убить кого-то к третьему дню.
 17) Надо спать :wink:
	Так. немного информации для тех, кто сюда недавно попал
	1) ICFP Contest - ежегодное соревнование приуроченное функциональному программированию
	2) Несмотря на то, что оно приурочено и связано с конференцией по функциональному программированию, можно участвовать на любых языках программирования.
	3) 72 часа без берерывов и выходных
	4) Каждый год задание разное и разной степени интересности и сложности. Задания прошлых годов легко гуглятся. Лучшим заданием IMHO есть задание 2006 года http://users.livejournal.com/-adept-/24049.html .
	5) Это немного не олимпиадного вида контекст. Но тут зависит от задания
	6) Язык - Kotlin :slightly_smiling_face: В этом году мы пишем на котлине. Близкоскриптовый, компилируемый, надо меньшче писать чем в джаве, поддерживает всю джаву из коробки
	7) Другие языки. В прошлом году мы попали на кейс, когда серверная часть писалась на другом языке, и часть команды, которая ее писала отвалилась после первого дня. (В принципе предупреждали, что так может быть, и люди делавшие эту часть потом ее суппортили, за что им отдельные кудос, но факт есть факт - мы недооценили важность такого момента).
	8) Remote vs onsite. Onsite лучче. Итерации очень быстрые и очень легко выбиться из контекста. А ко вторым 24 часам все будут очень раздраженные и никто не захочет по 5 раз обьяснять все :slightly_smiling_face:
	9) В виду того, что часто есть много аспектов задачи, приветствуются и настоятельно рекомендуются сообщения вида "Я сделал Х, его можно запускать Y, с параметрами Z отключить вот тут если вдруг что"
	10) На реализацию всего что приходит в голову времени нету. и(смотри 7й пункт) deal with it.
	11) Кривой, быстро работающий алгоритм намного лучше чем "правильно-сделанный-и-архитектурно-правильно-true-100%-clean-coded". 72 часа, особо не разгонишься. Особенно если это не критичная кусок кода.
	Пример. Мы для получения пересечения площади полигонов просто скармливали полигоны в CoreGraphics(аналог) рисовали их и считали пиксели. Реузльтат легко заменям, несложен для понимания, и занял пару 10 минут.
	12) Тесты маст хэв. Особенно те, которые покрывают спецификацию. Используемые стуктуры данных имеют свойство меняться достаточно быстро, и без тестов - мы будем сидеть в бесконечном дебаге. Благо это не swift, и тут все быстрее происходит. Почти во всех заданиях была некоторая виртуальная машина, либо формат данных, которого надо придерживаться, и как оказалось можно делать по 10 весьма тупых ошибок на одну строчку кода. Так что там, где есть спецификация - там должны быть тесты.
	Я не говорю про TDD, но тесты данные на вход-данные на выход нужны
	https://github.com/stanfy/icfpc2016/tree/master/src/test/kotlin/icfp16
	https://github.com/PaulTaykalo/icfp-2017/blob/master/src/test/kotlin/org/icfp2017/GameTest.kt
	13) По результатам предыдущих ICFP. Есть высока вероятность что после очередного брифинга, вы осознаете, что вы ничего не поняли, и вы не знаете за что браться. Это норма. Поймите, где вы лучше всего можете помочь, и закройте эту брешь. Не помогло? - дерните кого-нить и спросите чем можно помочь :wink: Лучше, конечно. быть проактивным. но иногда после потери контекста это сложно.
	14) Если задач меньше чем людей (маловероятно, но бывает) - то pair programming all the things.
	15) Ежечасовые 'hourly'(обсуждение статуса) в первые 24 часа. Дальше - По договоренности.
	16) Атмосфера. В условиях ограниченного времени и места, тон общения весьма накаляется, и возможно вы будете готовы убить кого-то к третьему дню.
	17) Надо спать :wink: