2008-11-25 SECR-2008: Наше выступление

From Wiki4Intranet
Jump to: navigation, search
(Import Blogger entry)
 
 
Line 1: Line 1:
SECR: Наше выступление
+
Выступление Андрея Бибичева, я к сожалению, проспал (всю ночь записывал диски с portable-версией MediaWiki), и конечно, хотя дали под выступление большой зал, раннее время — штука подлая. После первого унылого дня народу стало сильно меньше, а уж поднять себя на эту унылость к 9:00 смогли не все. Но вменяемые люди оценили — например, распорядитель первого зала был явно удивлен глубиной доклада (по сравнению с некоторой поверхностностью стандартных докладов ажайл-евангелистов), о чем он собственно и заявлял прямым текстом.
  
Выступление Андрея Бибичева, я к сожалению, проспал (всю ночь записывал диски с portable-версией MediaWiki), и конечно, хотя дали под выступление большой зал, раннее время — штука подлая. После первого унылого дня народу стало сильно меньше, а уж поднять себя на эту унылость к 9:00 смогли не все. Но вменяемые люди оценили — например, распорядитель первого зала был явно удивлен глубиной доклада (по сравнению с некоторой поверхностностью стандартных докладов ажайл-евангелистов), о чем он собственно заявлял прямым текстом.
+
Выступление Андрея Сатарина посмотреть удалось, в целом было удачно, в передних рядах народ был вполне в теме, и сразу стали атаковать вопросами в стиле «Continuous Integration для детских проектов, а наши проекты настоящего ''King Size'' размера, их фиг за ночь соберешь, не то, что по commit-у» (наезжающие стали соревноваться в длине сборки между собой). Тут я вмешался, и мне кажется, удачно парировал наезды, аргументируя необходимостью грамотной системы сборки, с использованием <tt>make/ant/scons</tt> — так как при нормальной, модульной структуре проектов и иерархических зависимостях, объем необходимой пересборки в среднем при любом коммите будет весьма ограничена. Например, если разбить объем сборки на сбалансированное бинарное дерево длины ''l'' с узлами равного объема, то даже в худшем случае (коммит «попал» в листовой узел) нужно выполнить объем в <m>\frac{2^{l+1}}{l}</m> раз меньший полного объема. Исключения, когда объем небъется на части есть — «создание базы и заполнение тестовыми данными», например, но для таких случаев тоже есть лайфхаки (например, база в памяти). Плюс, возможно придется бить на части набор юнит-тестов — (выполняемые по каждому коммиту, еженощно и т.п.). Как это делать, у меня конечно есть идеи (статистика срабатываний, важность накрываемого функционала и т.п), но надо посмотреть, что на этот счет говорит наука. Возможно при доработке этой презентации или разработки отдельной темы («Тонкости Continous Integration…») надо этот момент расписать и проиллюстрировать.
 
+
Выступление Андрея Сатарина посмотреть удалось, в целом было удачно, в передних рядах народ был вполне в теме, и сразу стали атаковать вопросами в стиле «Continuous Integration для детских проектов, а наши проекты настоящего King Size размера, их фиг за ночь соберешь, не то, что по commitу» (наезжающие стали соревноваться в длине сборки между собой). Тут я вмешался, и мне кажется, удачно парировал наезды, аргументируя необходимостью грамотной системы сборки, с использованием make/ant/scons — так как при нормальной, модульной структуре проектов и иерархических зависимостях, объем необходимой пересборки в среднем при любом коммите будет весьма ограничена. Например, если разбить объем сборки на сбалансированное бинарное дерево длины ''l'' с узлами равного объема, то даже в худшем случае (коммит «попал» в листовой узел) нужно выполнить объем в <html><img src="http://docs.google.com/File?id=dfxc7f9q_91gqbwhtd9_b" name="graphics5" align="bottom" border="0" width="23" height="31" /></html> раз меньший полного объема. Исключения, когда объем небъется на части есть — «создание базы и заполнение тестовыми данными», например, но для таких случаев тоже есть лайфхаки (например, база в памяти). Плюс, возможно придется бить на части набор юнит-тестов — (выполняемые по каждому коммиту, еженощно и т.п.). Как это делать, у меня конечно есть идеи (статистика срабатываний, важность накрываемого функционала и т.п), но надо посмотреть, что на этот счет говорит наука. Возможно при доработке этой презентации или разработки отдельной темы («Тонкости Continous Integration…») надо этот момент расписать и проиллюстрировать.
+
  
 
Мое выступление особо удачным не было, хотя я даже было надеялся сыграть на контрасте, ибо на предыдущем докладчике зал просто заснул, но как только предыдущий доклад завершился почти вся аудитория начала бегство из зала, подумав, что здесь пытают скукой. Вообще я был под сильным стрессом, ибо не был уверен, что 112 слайдов презентации реально уложить в 30-35 минут, а выкидывать слова из песни очень не хотелось — там была целостная мысль, резать ее было почти нереально. 112 слайдов на самом деле не так много, ибо это я пробовал новый, устойчивый к плохому разрешению и малым экранам стиль презентации — «полумультфильм», где одна мысль или классификация разбивались на несколько слайдов, а концепты-понятия появлялись на слайдах по очереди, так, что граф отношений понятий строился постепенно, а наиболее ключевые понятия показывались и дольше, и крупнее. Единственное — выкинул ответы на частозадаваемые вопросы — и все эти вопросы мне потом ожидаемо задали в кулуарах. Но все равно, пришлось пожертвовать театральными паузами, и следовательно смехом в зале (юмор без пауз, где смеяться, не воспринимается), да и в целом, контактом с аудиторией. В результате, выглядел скорее комично, чем авторитетно, как я выглядел на предыдущем SECRе, и в кулуары за мной увлеклась группа скорее молодых разработчиков, чем менеджеров (людей в костюмах вроде не было).
 
Мое выступление особо удачным не было, хотя я даже было надеялся сыграть на контрасте, ибо на предыдущем докладчике зал просто заснул, но как только предыдущий доклад завершился почти вся аудитория начала бегство из зала, подумав, что здесь пытают скукой. Вообще я был под сильным стрессом, ибо не был уверен, что 112 слайдов презентации реально уложить в 30-35 минут, а выкидывать слова из песни очень не хотелось — там была целостная мысль, резать ее было почти нереально. 112 слайдов на самом деле не так много, ибо это я пробовал новый, устойчивый к плохому разрешению и малым экранам стиль презентации — «полумультфильм», где одна мысль или классификация разбивались на несколько слайдов, а концепты-понятия появлялись на слайдах по очереди, так, что граф отношений понятий строился постепенно, а наиболее ключевые понятия показывались и дольше, и крупнее. Единственное — выкинул ответы на частозадаваемые вопросы — и все эти вопросы мне потом ожидаемо задали в кулуарах. Но все равно, пришлось пожертвовать театральными паузами, и следовательно смехом в зале (юмор без пауз, где смеяться, не воспринимается), да и в целом, контактом с аудиторией. В результате, выглядел скорее комично, чем авторитетно, как я выглядел на предыдущем SECRе, и в кулуары за мной увлеклась группа скорее молодых разработчиков, чем менеджеров (людей в костюмах вроде не было).
Line 13: Line 11:
 
С другой стороны, вполне можно повторить тему доклада про MediaWiki (проработав дополнительные части, например UML-графы по текстовому описанию), на конференции типа РИТ, без боязни прослыть «баянистом» (если возьмут, конечно).
 
С другой стороны, вполне можно повторить тему доклада про MediaWiki (проработав дополнительные части, например UML-графы по текстовому описанию), на конференции типа РИТ, без боязни прослыть «баянистом» (если возьмут, конечно).
  
И все же, надо продолжать светится при возможности на этой конференции, ибо аудитория этой конференции есть, и она почти не пересекается с «интернетными» конференциями РИТ/Highload (возможно поэтому отзывов в блогах и мало, может по курилкам-то обсуждения и пошли). На SECRе есть такие редкие категории, как участники из регионов, депутаты, IT-бизнесмены и менеджеры и т.п.<br />
+
И все же, надо продолжать светится при возможности на этой конференции, ибо аудитория этой конференции есть, и она почти не пересекается с «интернетными» конференциями РИТ/Highload (возможно поэтому отзывов в блогах и мало, может по курилкам-то обсуждения и пошли). На SECRе есть такие редкие категории, как участники из регионов, депутаты, IT-бизнесмены и менеджеры и т.п.
 
{{wl-publish: 2008-11-25 19:52:00 +0300 | StasFomin}}
 
{{wl-publish: 2008-11-25 19:52:00 +0300 | StasFomin}}

Latest revision as of 21:24, 9 March 2011

Выступление Андрея Бибичева, я к сожалению, проспал (всю ночь записывал диски с portable-версией MediaWiki), и конечно, хотя дали под выступление большой зал, раннее время — штука подлая. После первого унылого дня народу стало сильно меньше, а уж поднять себя на эту унылость к 9:00 смогли не все. Но вменяемые люди оценили — например, распорядитель первого зала был явно удивлен глубиной доклада (по сравнению с некоторой поверхностностью стандартных докладов ажайл-евангелистов), о чем он собственно и заявлял прямым текстом.

Выступление Андрея Сатарина посмотреть удалось, в целом было удачно, в передних рядах народ был вполне в теме, и сразу стали атаковать вопросами в стиле «Continuous Integration для детских проектов, а наши проекты настоящего King Size размера, их фиг за ночь соберешь, не то, что по commit-у» (наезжающие стали соревноваться в длине сборки между собой). Тут я вмешался, и мне кажется, удачно парировал наезды, аргументируя необходимостью грамотной системы сборки, с использованием make/ant/scons — так как при нормальной, модульной структуре проектов и иерархических зависимостях, объем необходимой пересборки в среднем при любом коммите будет весьма ограничена. Например, если разбить объем сборки на сбалансированное бинарное дерево длины l с узлами равного объема, то даже в худшем случае (коммит «попал» в листовой узел) нужно выполнить объем в раз меньший полного объема. Исключения, когда объем небъется на части есть — «создание базы и заполнение тестовыми данными», например, но для таких случаев тоже есть лайфхаки (например, база в памяти). Плюс, возможно придется бить на части набор юнит-тестов — (выполняемые по каждому коммиту, еженощно и т.п.). Как это делать, у меня конечно есть идеи (статистика срабатываний, важность накрываемого функционала и т.п), но надо посмотреть, что на этот счет говорит наука. Возможно при доработке этой презентации или разработки отдельной темы («Тонкости Continous Integration…») надо этот момент расписать и проиллюстрировать.

Мое выступление особо удачным не было, хотя я даже было надеялся сыграть на контрасте, ибо на предыдущем докладчике зал просто заснул, но как только предыдущий доклад завершился почти вся аудитория начала бегство из зала, подумав, что здесь пытают скукой. Вообще я был под сильным стрессом, ибо не был уверен, что 112 слайдов презентации реально уложить в 30-35 минут, а выкидывать слова из песни очень не хотелось — там была целостная мысль, резать ее было почти нереально. 112 слайдов на самом деле не так много, ибо это я пробовал новый, устойчивый к плохому разрешению и малым экранам стиль презентации — «полумультфильм», где одна мысль или классификация разбивались на несколько слайдов, а концепты-понятия появлялись на слайдах по очереди, так, что граф отношений понятий строился постепенно, а наиболее ключевые понятия показывались и дольше, и крупнее. Единственное — выкинул ответы на частозадаваемые вопросы — и все эти вопросы мне потом ожидаемо задали в кулуарах. Но все равно, пришлось пожертвовать театральными паузами, и следовательно смехом в зале (юмор без пауз, где смеяться, не воспринимается), да и в целом, контактом с аудиторией. В результате, выглядел скорее комично, чем авторитетно, как я выглядел на предыдущем SECRе, и в кулуары за мной увлеклась группа скорее молодых разработчиков, чем менеджеров (людей в костюмах вроде не было).

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

Лично я получил всего пару приглашений в мойкруг и писем с критикой. Хотя критикой полезной, ибо совсем забыл про проблему русских имен файлов под переносимой под Windows сборкой MediaWiki, эту проблему нужно все равно будет решать.

С другой стороны, вполне можно повторить тему доклада про MediaWiki (проработав дополнительные части, например UML-графы по текстовому описанию), на конференции типа РИТ, без боязни прослыть «баянистом» (если возьмут, конечно).

И все же, надо продолжать светится при возможности на этой конференции, ибо аудитория этой конференции есть, и она почти не пересекается с «интернетными» конференциями РИТ/Highload (возможно поэтому отзывов в блогах и мало, может по курилкам-то обсуждения и пошли). На SECRе есть такие редкие категории, как участники из регионов, депутаты, IT-бизнесмены и менеджеры и т.п.