Я умею пребывать в двух режимах: воспринимающий и генерирующий.
В первом режиме я читаю френдленту, новости, разбираюсь в чем-то, на что наткнулся и т.д. В общем нахожусь в курсе того, что вокруг меня происходит.
Во втором режиме я что-то делаю сам. Придумываю, структурирую, создаю.
Наблюдения показывают, что чем меньше я смешиваю эти две деятельности, тем лучше получается каждая из них.
Проблема в том, что через неделю генерирующего режима мне приходится просматривать сотни сообщений из френдленты и rss-читалки. Это так угнетает! :-)
В эти выходные был ICFPC 2009 — соревнование по программированию в стиле марафон for fun.
Суть — создать программу управления спутником для выполнения одного из нескольких заданий. Не буду расписывать все тонкости, если кратко, то сначала надо было просто сменить спутнику орбиту, потом состыковаться с другим спутником (выйдя на его орбиту рядом с ним), потом состыковаться со спутником, находящимся на эллиптической орбите. А потом облететь все спутники, заглядывая в промежутках на заправки за бензином.
До облета всех мы не дошли, поэтому смотрите примеры только первых трех:
Прежде чем приступить к пилотированию пришлось написать виртуальную машину, исполняющую некоторый бинарный машинный код. Потом эту виртуальную машину пришлось переписать в компилятор этого машинного кода в С#, чтобы было побыстрее. А вот фрагмент дизассемблированной программы симулятора движения космического спутника:
00000 nop mem: 1
00001 mov mem[1] <- mem[265] mem: 0
00002 nop mem: 30
00003 nop mem: 0
00004 mov mem[4] <- mem[248] mem: 0
00005 - mem[5] <- mem[4] - 0 mem: 0
00006 cmp status <- mem[5] == 0.0 mem: 0
00007 phi mem[7] <- status ? 30 : mem[1] mem: 0
00008 - mem[8] <- mem[7] - 1 mem: 0
00009 mov mem[9] <- mem[263] mem: 0
00010 cmp status <- mem[5] == 0.0 mem: 0
00011 phi mem[11] <- status ? 1 : mem[9] mem: 0
00012 - mem[12] <- mem[11] - 1 mem: 0
00013 cmp status <- mem[12] == 0.0 mem: 0
00014 phi mem[14] <- status ? mem[8] : mem[7] mem: 0
00015 mov mem[15] <- mem[264] mem: 0
00016 nop mem: 1000
00017 cmp status <- mem[5] == 0.0 mem: 0
00018 phi mem[18] <- status ? 1000 : mem[15] mem: 0
00019 nop mem: 2
00020 * mem[20] <- mem[18] * mem[19] mem: 0
00021 cmp status <- mem[12] == 0.0 mem: 0
00022 phi mem[22] <- status ? mem[20] : mem[18] mem: 0
00023 cmp status <- mem[12] == 0.0 mem: 0
00024 phi mem[24] <- status ? mem[18] : mem[12] mem: 0
00025 mov mem[25] <- mem[260] mem: 0
00026 mov mem[26] <- mem[262] mem: 0
00027 nop mem: 1,1
00028 nop mem: 42164
00029 * mem[29] <- 42164000 mem: 0
00030 / mem[30] <- mem[29] / mem[27] mem: 0
Плохо спал. Всю ночь снилось как я не могу выйти на нужную эллиптическую орбиту.
Отчет типа вот этого о прошедшем мероприятии будет позже.
Кто-то недавно спрашивал у меня крейсерскую скорость роликов.
Сегодня проехал от УПИ до дома на Эльмаше 9.2 км за 45 минут. Ехал после тренировки, поэтому не спешил. Но и не полз — это не приносит удовольствия. :)
Получается, что крейсерская скорость примерно 12 км/час = 200 м / мин.
Это в два раза больше моей крейсерской пешеходной скорости.
Настоящие цели — всегда персональные. Если человек говорит, что его цель — "сделать так, чтобы компания/страна X обогнала всех остальных по показателю Y", то он как минимум чего-то недоговаривает. Или просто не до конца сам осознает.
Человек так устроен, что ему нравиться делать то, от чего он получает удовольствие.
Так вот, кажется, что все цели строятся вокруг этого простого человеческого качества: нашли занятие, от результатов которого вас прет — поставили цель, чтобы от этого вас перло ещё больше!
Если человек научился получать удовольствие от того, что по городу катается куча роллеров, которых он самолично учил самым базовым вещам, то целью может быть совершенствование школы роллеров.
Если человек научился получать удовольствие от принятия эффективных стратегических решений, которые очень хорошо сказываются на состоянии компании, в которой он работает, то целью будет сделать как можно больше как можно более эффективных менеджерских решений.
Если человек получает кайф, если тупо рубиться в Half-life, целью может быть стать чемпионом мира по этой игре.
ОК. Но бывают же еще и цели всяких компаний и организаций. Что это такое?
А это такой своеобразный маячок, который сообщает окружающим, что вокруг него тусуются люди, цели которых как-то коррелируют с обозначенной целью. И если очевидно, что твоя личная цель и цель компании могут друг другу взаимопомочь, то вам с компанией по пути. Другими словами, люди в этой компании с большей вероятностью будут принимать такие решения, которые будут помогать вам достигать собственной цели.
Например, если моя цель вывести с нуля на рынок новый интересный интернет-сервис, то мне выгодно сотрудничать с компаниями, у которых цель заработать кучу денег и известности на новых интернет-сервисах.
Все развитие человечества в конце концов строится на том, что разные люди с разными целями объединяются и, взаимодействуя, помогают друг другу достичь своих целей.
Есть у нас на работе три библиотеки, с которыми приходилось иметь дело довольно давно:
Core — общие утилитки.
Cryptography — обертки над CryptoAPI и родными интерфейсами других криптобиблиотек.
Channel — реализация транспортного уровня Контур-Экстерна.
Проблема в том, что Channel зависит от двух остальных, а Cryptography зависит от Core.
Каждый шаг влево/вправо грозил перевыпуском всей тройки.
Проблема ещё и в том, что Core и Cryptography находятся во власти нашей группы разработки, а Channel нет.
В общем, к дню независимости мы сделали так, что ни одна библиотека больше не зависит ни от одной другой. Ура товарищи!
PS. Какая-то у меня неделя ответов на посты ![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
fdo_eq получилась.
Что такое Free skating на роликах, спросите вы?
Вот вам мегавидео (67 Мб!), которое даст ответ.
Главные герои, конечно, нереально круты! :-)
fdo_eq когда-то приводил свою версию целей преподавания. Тогда я в общем-то согласился с этой формулировкой, а вот сейчас понял, что у меня формулировочка почти неуловимо отличается.
На мой взгляд будет правильно, если я, преподаватель, буду ставить перед собой цель воспитания человека, в результате которого (в порядке убывания важности):
1. Этому человеку комфортно в этом мире.
2. Мне комфортно в мире, где есть это человек.
3. Остальным людям, с которыми мне комфортно станет комфортнее от появления такого человека.
Да, слово "комфортно" как и прежде определено чисто интуитивно. :-)
Несколько лет назад (не могу вспомнить сколько) я перестал носить на руке часы в пользу часов в мобильнике.
Примерно тогда же я придумал себе простую развивающую игру. Каждый раз, когда мне хотелось узнать время, я сначала сам прикидывал, сколько по моим ощущениям сейчас времени, а лишь потом лез в карман за мобильником.
Несколько лет подобных тренировок привели к результатам, которые иногда пугают меня самого.
Если я нахожусь в привычной обстановке, то промежутки времени длиной в час-два я могу отмерять с точностью 3-5 минут. Если при этом я передвигаюсь по городу, пешком или на общественном транспорте, то я могу предсказывать время прибытия в назначенную точку с точностью все те же 5 минут.
Забавно, что в необычной и непривычной обстановке ошибки могут быть в разы больше. Я могу за три часа страйкбола ошибиться на час. Правда на втором страйкболе внутренний хронометр будет уже заметно точнее.
Собственно идея этого поста пришла ко мне в тот момент, когда я возвращался домой с тренировки. На полпути, в метро, я сообразил, что забыл сделать дело, ради которого нужно было вернуться на метро обратно на пару станций, выйти из него, некоторое время поделать это дело и после этого вернуться обратно домой. Буквально секунды 3 мне потребовалось, чтобы оценить, что все это займет у меня 56 минут (времени было на часах 21-34, а оценил возвращение домой я в 22-30). В реальности заняло 55 минут. Как же тут не написать про это пост! :)
Вот такой вот забавный факт.
Нет устоявшегося мнения, что должно происходить по одинарному клику по иконке в трее, а что по двойному. Все делают как бог на душу положит. Одному больше удобно одинарный, другому больше нравиться двойной. Зоопарк ужасный.
Например, Bat и Miranda открываются по одинарному. А по двойному открываются и тут же закрываются.
Персональный поиск от яндекса на одинарный выводит контекстное меню, причем с такой задержкой, что по началу думаешь, что он на одинарный вообще не реагирует. Сам поиск открывается по двойному.
Винамп появляется по одинарному клику.
Windows Defender - по двойному.
Многие системные иконки ведут себя так: по одинарному маленькое окошко с управлением, по двойному большое окошко с управлением.
Outlook, кажется, тоже открывается по двойному.
Я пользуюсь мирандой уже года три. Я все ещё ее открываю за три клика: даблклил - она появляется и исчезает. После этого я вспоминаю, что нужно делать просто клик и делаю третий клик.
Хватит ломать мозг пользователям! Пишите свои программы так, чтобы клик и даблклик по иконке в трее вели себя ОДИНАКОВО!
Ну вот. Меня все кому не лень начали хвалить. Это же бред!
Хороший Преподаватель переворачивает мироощущение обучаемого. Меняет его. Дает ему что-то, что он будет помнить ещё много лет.
Мне повезло, у меня в жизни было несколько Преподавателей с большой буквы. Пожалуй не грех их тут перечислить.( Read more... )
А теперь, внимание, главный вопрос вселенной и всего такого. Чувствую ли я, что изменил мироощущение хоть одного студента сравнимо по силе с тем, как изменили его во мне перечисленные Преподаватели? Ответ - нет.
Методы методами, а главное все равно результат. Так нечего меня зря хвалить, лучше делом займитесь... :(
Недавно я хотел странного. Мало кто понял, чего я хочу, а объяснять подробно мне было лень.
Сейчас я, кажется, нашел способ объяснить это очень просто.
Convention over configuration — это подход к проектированию, при котором устанавливается очень удобное поведение по умолчанию, которое восстанавливает необходимую информацию непосредственно из структуры кода и не требует указания этой информации явно. Идея в том, чтобы упростить разработку, позволяя разработчику заботиться только о тех частях программы и архитектуры, для которых умолчания не подходят.
http://msdn.microsoft.com/en-us/magazin
Комрад khazzar тут жалуется на студентов-неучей, которые один класс от другого унаследовать не могут.
Раньше я себе думал, что как-то хиленько у меня студенты на парах пашут. Сейчас я понимаю, что по сравнению с УПИ они буквально 5 га за вечер вспахивают. Каждый. Это ужасно, потому что я знаю, что в Московских и Питерских ВУЗах все ещё жестче. Там, если продолжать аналогию, вспахивают по 20 га.
Я тут вижу всего две возможные причины.
1. Вполне возможно, что атмосфера УПИ предрасполагает к такому отношению к учебе.
2. Вполне возможно, что подход к обучению студентов Саши не очень подходит к той публике, с которой он работает.
Про п.1 я ничего не знаю, а о п.2 хочется сказать пару слов.
Если в целом, то правила игры "учиться не заставляем, но даем возможность" не работает. Если судить по наглядным графикам успеваемости, которые составляет наш декан, то эти правила начали переставать работать лет 6 назад и с тех пор их действенность стабильно ухудшалась. Сейчас, по крайней мере в УрГУ опомнились. Все, надо перестраиваться. Иначе учеба будет превращаться в отсидку, а в универе останутся лишь самые пофигистические преподаватели, которых не особо волнует уровень выпускников.
Сейчас студентов надо именно заставлять. Причем не грубой силой, а хитрыми приспособлениями, заманухами, ловушками. Хитростью и смекалкой.
В частности, чтобы хоть что-то сдвинулось с места, студентов нужно замотивировать. Так получается, что я работаю с группами, которые теоретически должны быть замотивированы сами собой: второй курс компьютерных наук и магистратура по технологии разработки ПО. И если с магистратурой никаких проблем действительно нет, то с КН-202 приходится поработать. Кризис, кстати, немного мне поможет с этим в будущем году! :)
Дальше просто перечислю набор выдуманных мной приемчиков:
0. Обзор, гм... рынка труда разработчиков ПО. :-) С примерным уровнем ЗП в зависимости от квалификации.
1. 5-10 минут в начале практики на "лирическоетеоретическое отступление". Это всем очень нравится!
2. Несколько дедлайнов, распределенных по семестру. Не вписываешься в дедлайн — придется делать больше задач. Стимулирует работать во время семестра, а не только ближе к концу.
3. Зачет исключительно автоматом. Для автомата нужно сдать кучку задач. Более менее сильные студенты с кучкой справляются за одну две недели интенсивного труда. Менее сильные пашут весь семестр без перерыва.
4. Напоминалки по почте о том, что гредёт дедлайн. (надо чаще практиковать!)
5. Переписка по поводу задач со студентами по почте заставляет их работать и между парами. (О, блин, как это тяжко!)
6. Мягкое усложнение задачи, которое у студента получилось слишком легко. Обычно, после этого студент говорит что-то типа "круто! получилось так хитро и умно!". Мне такие моменты очень нравятся.
7. Обсуждения сложных мест в решении на парах и в почте. Рисование UML-диаграм квадратиков и стрелочек на доске, рассуждение об архитектуре вслух.
8. Дружественное отношение, так, чтобы не боялись, чтобы на пары было приходить приятно. Шутки юмора, но не в ущерб, конечно.
9. Рассказывать студентам моё промежуточное мнение об этих студентах. Например: "Вы постоянно втыкаетесь в незнание возможностей языка, о которых вам рассказывали на лекции. Если так пойдет дальше, то на экзамене вы рискуете схватить трояк. Материал лекций у вас есть в электронном виде. Если вы потратите сейчас немного времени, чтобы поднять этот материал, вам будет на много легче и сейчас и потом."
10. Периодические коротенькие рассказы про то "а как у нас на работе устроено то-то", а кто тот человек, который недавно приезжал из Израиля в УрГУ читать публичные лекции, а кто и как придумал такие-то принципы проектирования.
11. Ещё в этот раз попрактиковал такой подход. "У вас плохое решение. Хотите приехать ко мне на работу и потратить полтора часа времени на то, чтобы вместе преобразовать это решение к хорошему виду?" Поскольку попрактиковал в конце курса, то измерить результат не знаю как. Но по устным заверениям студента, было крайне полезно и поучительно.
Вот как то так. Сил это требует много, но, по-моему, либо так, либо лучше вообще никак.
Если у кого-то есть альтернативное мнение на эту тему или просто мысли, можете считать этот пост приглашением к обсуждению. Всегда рад!
Мое увлечение ледовыми коньками как-то само собой загнулось. Может быть потому что катки — штука непостоянная и с непредсказуемым качеством льда. Может просто надоело.
В общем я сейчас начинающий роллер. Как оказалось:
1. Стать полноценным роллером можно всего за 8000р = 5000 ролики + 1000 защита + 2000 рюкзак для роликов.
2. Если просто аккуратно и не быстро ездить по городу, то защита остается не при делах.
3. Если учиться делать что-то более менее интересное (разворот на 180 прыжком, power slide, просто езда задом), защита незаменима!
4. Не знаете зачем нужны налокотники? А я теперь знаю! Я успел два раза покоцать свой локоть и оба раза при езде назад. Все происходит примерно так: ролик во что-то втыкается, ты аккуратно и небольно падаешь на спину, группируешься, тебя немного поворачивает, ты чуть-чуть касаешься локтем асфальта и вуаля!
5. В Екатеринбурге каждое воскресенье проводятся воскресные покатушки — все желающие едут по заранее выбранному маршруту длиной километров в 12-15. Все под присмотром и контролем старших товарищей. На одной из таких покатушек я поверил в то, что ролики — это средство передвижения.
6. В Екатеринбурге есть сайт роллеров http://www.eroller.ru, на котором, собственно, и организуются покатушки.
7. На упомянутом http://www.eroller.ru есть возможность записаться в группу к хорошим тренерам, которые научат вас: А) базовым навыкам; Б) продвинутым штуковинам (так называемый FSK — Free skating); В) Слалому (прикольное объезжание фишечек). Что поражает больше всего — так это стоимость таких курсов. Всего 150 р за двухчасовое занятие.
8. После одного занятия FSK под тренерством Storg-а очень болят мышцы спины и ног.
А в общем и целом, это круто! :)
Чуть не забыл! Всем рекомендую познакомиться с главным сюрпризом от google — новым мегапродуктом/платформой/протоколом — Google Wave. Как презентация, так и сам Wave на мой взгляд супер-круты:
http://wave.google.com/
Я, конечно, тот ещё предсказатель, но мне кажется, что если у них все получится, то скоро email, IM-ы, wiki и форумы начнут медленно но верно становиться архаизмами.
Wave весь из себя открытый, расширяемый, встраиваемый вроде бы опенсорсный, но ещё находится в стадии разработки. Но если вы знаете, чем его можно было бы расширить, то можно попросить тестовый аккаунт.
Круто, что тут скажешь!
Кто-то жаловался, что я перестал писать в блог? Исправляюсь.
Итак, проблема! Есть процесс разработки ПО в конкретно взятой группе разработки. Процесс под руководством тимлида или менеджера постоянно корректируется, появляются новые практики, меняется состав команды разработчиков и т.п. Вот бы неплохо было бы знать, как это все отражается на боеспособности команды.
Для этого давным давно выдумали такие штуки, как метрики. Давайте их мерить и смотреть на результат.
Тут есть несколько подводных камней, но в этом посте я хочу затронуть только один.
Для тех, кто готов разорвать меня на кусочки за то, что я собираюсь кого-то померить, сообщаю — да, я знаю, что при неаккуратном обращении с метриками они вырождаются, становятся бесполезными и даже приносят вред. Речь не о том, как с ними обращаться аккуратно — об этом, возможно, будет отдельный пост.
Тут же я хочу поговорить о барьере вхождения. Момент, когда можно сделать первые выводы из метрик отделяется от момента, когда их начали собирать довольно длительным промежутком времени. Это многих останавливает: "да, мы потратим сейчас целую неделю труда, чтобы наладить сбор таких-то метрик, но окупиться это дай бог только через полгода — ужас!". Вот бы можно было махнуть волшебной палочкой, топнуть ногой, повернуться через левое плечо и волшебным образом получить метрики за предыдущие пару лет. Магия, да? Нифига не магия. Все просто до тупости — исходники лежат в svn, хранящем историю за все время жизни. Треккер хранит баги и фичи за всё время его пользованием. Wiki хранит документы со спецификациями за все время ее использовния. Логи хранят информацию об использовании вашего веб-решения за последнее время (вы ведь их не удаляете, да?). Нужно только придумать как из всех этих инструментов доставать нужную информацию. Своеобразное путешествие во времени.
Вот, например, банальную LOC можно собирать очень тупо по SVN-у. Чекаутим каждую ревизию, считаем, выкидываем. Ну или чуть умнее, чекаутим только первую версию, а остальное досчитываем по diff-ам.
Или вот я придумал измерять так называемый Internal Rate — величина, коррелирующая с объемом усилий, которые были сделаны разработчиками — количество измененных или добавленных строк кода, за исключением вливаний веток, массовых переименований и подобного.
Есть у кого-то ещё идеи полезных метрик, которые можно собирать за прошедшее время, без предварительно проведенной подготовки?
Товарищ Гапертон предложил недавно планировать не в терминах задач, а в терминах целей. Кому-то может показаться эта идея революционной (вот ему уже и тренинг заказали!), а для меня она показалась очень естественна и очевидна. Просто у меня уже есть некоторый опыт превращения задач в цели.
Некоторое количество людей в контуре уже несколько лет проповедуют подход "Делитесь проблемами". Подход предполагает, что все люди, которые что-то хотя от разработчиков должны приходить к ним не с задачами и не с готовыми решениями (сделайте мне такую вот кнопку), а с проблемами или целями. При этом подавляющее большинство целей формулируется так "решить такую-то проблему", поэтому я выделил проблему отдельным пунктом, да ещё и выделил жирным.
Если приходит к тебе служба поддержки и говорит, сделайте чтобы работало вот так! Это звоночек. Не нужно делать так как они говорят. Вместо этого надо взять горячий утюг провести глубинный допрос и понять, какая проблема подтолкнула их к такому запросу. В процессе исследования проблемы часто оказывается, что делать нужно немного не так, как они предлагают. Просто потому что они не подумали о десятке других проблем других людей, приходивших ранее к разработчикам.
Если приходят менеджеры и говорят, "Нам нужен биллинг! Крутой, навороченный биллинг!", то худшее, что можно сделать — это начать писать навороченный биллинг. Вместо этого нужно взять паяльник узнать какие проблемы подталкивают менеджеров к тому, чтобы заиметь биллинг. Не удобно продавать то-то? Почему неудобно? Потому что долго выписывать кракозяблу? Почему? Финтифлюшки нет? А-а.. Так финтифлюшку мы вам сделаем в 100 раз быстрее, чем биллинг. Ну ладно, сделаем в 20 раз быстрее, но с учетом того, что финтифлюшку можно будет потом расширить до крутого навороченного биллинга. Если понадобится... Ага...
Если приходит ещё кто-нибудь и спрашивает, когда же наконец мы сделаем фичу Ф, то не нужно ничего умножать на ПИ! Нужно ответить по-еврейски вопросом на вопрос: а когда надо? Вернее даже "зачем надо?". Типа, "какая проблема тебя привела к нам, мужик?" Тут обычно у обозначенного мужика начинается ломка, но она всегда очень продуктивна и полезна. Человек вымучивает из себя внешние сроки, от которых можно оттлакиваться: Ну, тогда-то назначен срок окончания пилотного проекта. За две недели до этого начнется собственно главная отчетность, по которой будут подбивать результаты пилота, за недельку бы иметь релиз с такими-то самыми желаемыми доработками. Ага, значит ещё за недельку до этого надо его отдать релиз-кандидат в тестирование. На разработку остается столько-то времени. Конкурирующие задачи у нас такие-то и такие-то. Все! Все данные есть можно аккуратно высчитывать и понимать, успеваем мы с запасом / успеваем впритык / успеваем, если пожертвует еще чем-то / не успеваем совершенно точно. Тяжелый процесс согласования приоритетов нужен, кстати, только в одном из этих 4 случаев.
Все эти три сценария имеют одно общее — должна быть сформулирована проблема или цель! Если сформулирована не цель, а ещё что-то — задача / фича / идея решения — нужно поднимать тревогу и докапываться до цели—проблемы. Иначе не работает.
Хочу докрутить StructureMap (это такой DI / IoC контейнер с человеческим лицом), сделав из него Zero-friction edition:
1. На предмет плагинов и сервисов просматрваются все сборки, в директории приложения и всех поддиректориях. При невозможности загрузить сборку она пропускается.
2. По умолчанию в контейнере регистрируются вообще все найденные интерфейсы в качестве сервисов (pluginFamily).
3. Все неабстрактные реализации этого интерфейса считаются плагинами и регистрируются в контейнере.
Кажется должно быть очень просто и эффектно, но вижу пару подводных камней.
А какие подводные камни видите вы?
Лекция была про паттерны. Паттерны никогда не оказывают такого мощного эффекта на сознание, поэтому показалось, что в этот раз Кент Бек не жог. Но жог ли он на самом деле покажет будущее, когда я эти паттерны попробую пару десятков раз примерить к своим действиям.
Мой конспект. На этот раз, к сожалению, он не заполняет пространство листа так гармонично, как в прошлый раз.
На всякий случай поясню, что карту может нормально прочитать лишь человек бывший на лекции. Возможно, карта поможет кому-то вспомнить содержимое лекции, или восстановить пропущенные куски, или структурировать информацию у себя в голове.
Вчера и сегодня на тренинге Кент Бек сначала заставлял нас отвечать, а потом рассказывал свой ответ на очень жесткий и мощный вопрос: «Как бы был устроен процесс разработки, если он был на мои собственные деньги?». Наше мнение было довольно спонтанным и хаотическим и довольно походило на то, что уже итак есть в контуре. Тут же я расскажу о безумной идеи самого Бека.
( Read more... )
Navigate: (Previous 20 Entries)