Хотите что-нибудь спросить у меня на произвольную тему? Спрашивайте! Этот пост специально для этого. Если я сочту вопрос корректным — отвечу. И даже против анонимных вопросов ничего не имею.

Вообще-то у меня есть аккаунт на formspring.me (http://www.formspring.me/xoposhiy), но, как выяснилось, он косячный :)

Расскажу ка я вам сегодня один поучительный прием, подсмотренный при изучении одного довольно скучного протокола :-)

Есть такой узко-специализированный протокол AS2 RFC 4130, использующийся в основном торговыми сетями и их поставщиками для передачи информации о заказах и отгрузках. Но сам протокол про отгрузки и заказы ничего не знает, он просто определяет то, как передается файлик over HTTP и как нужно отправлять в ответ на файлик квитанцию о получении файлика.

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

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

• Добавить HTTP-заголовок "Disposition-notification-to". Это будет означать, что вы в принципе хотите получить обратно квитанцию.


• Добавить HTTP-заголовок "Receipt-Delivery-Option: return-URL". Это будет означать, что вы хотите получить квитанцию именно асинхронно, через некоторое время, отдельным HTTP-запросом на указанный URL.

Оставим за скобками странные названия у этих заголовков. На то есть свои причины, которых касаться уже не так интересно. Сконцентрироваться хочется на вопросе: зачем в запросе асинхронной квитанции ещё раз указывать, куда эту квитанцию отправлять, ведь все итак знают по какому адресу нужно отправлять сообщения, чтобы их получил тот, кто надо! Между тем в rfc явно написано, что отправлять квитанцию нужно именно по return-URL, а не куда-либо ещё.

Вот вам несколько секунд на подумать, пока вы открываете текст под катом.
( Читать дальше... )

УИК 1657, мой родной.

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

Подвозов, каруселей и прочих аномалий не было.

КОИБы были. КОИБы делают процесс подсчета на порядки более простым, контролируемым и цивилизованным. Если, конечно, верить в то, что они считают все правильно. Но вроде оснований сомневаться пока нет.

58% за Путина
18% за Прохорова.
Остальные меньше.
15 штук испорченных.

Большинство голосующих — пенсионеры. При вскрытии урн, визуально, за Путина действительно много. На глаз 45 от 58 совсем не отличается, конечно, но много.
Так что как это ни печально, но кажется, Путин — это действительно воля народа на моем участке.

Наблюдателей от ЕР было двое:
Одна приятная женщина (учитель начальных классов) как обычно, за деньги. Немного смущалась, когда ее спрашивали "от кого она наблюдатель". Ещё один парень из юр-академии бесплатно от "за чистые выборы". Не жулик и не провокатор, как обещал нам Навальный. Немного халявил, но в целом работал на то, чтобы все было честно и правильно. Кажется, идейный. Даже если Корпус и проНашистский, то полагаю, куча наблюдателей от него вполне себе честные и идейные.

На этот раз с комиссией у меня вышло все гораздо более дружнее, чем в прошлый раз. Поблагодарили друг-друга в конце. Все было честно.

Очень часто встречаю чужие проекты, которые сходу не компилируются, потому что хотят какой-то неведомой внешней зависимости. Я понимаю, почему это встречается у лихих студентов — когда они ставят ссылку в Visual Studio на внешнюю библиотечку, они особо и не понимают что за этим стоит. Но ведь часто это и у зрелых проектов наблюдается!

А ведь в большинстве случаев это так просто — все зависимости носить с собой!



1. Создаем папочку в проекте с названием "external"
2. Складываем туда все dll-ки, от которых что-то зависит (в первую очередь всеми любимый nunit.framework.dll)
3. Добавляем зависимости не из GAC-а, а из этой папочки.

Voila! Теперь проект компилируется на любой машине вне зависимости, установлен там nunit или нет.

Появилась новая зависимость? Первое что делаем, это копируем в папочку external.
Хотите перейти на следующую версию библиотеки? Заменяем в папочке external и пробуем собрать / запустить.

Удобно!

УИК 1655 на самом краю Космонавтов.

Накануне пришел познакомиться с председателем. С виду милая, симпатичная женщина. Сегодня, в день выборов окзаалось, что она ещё и отличная организаторша. Все работает как часы. В частности в комиссии есть два члена-помощника, которые не работают с бумажками, а просто наблюдают и следят за порядком. В частности они три раза останавливали людей, пытавшихся вынести бюллетень. Все три раза выносили не со зла: один раз потому что сведения о кандадатах вывешены на входе в зал голосования, а не в самом зале. Чел решил вернуться почитать, держа в руках бюллетени. Второй раз девушка опустила в урну два бюллетеня, а третий сложила и пошла на выход. Что это было не понятно, скорее всего она просто не захотела голосовать по одному из трех вопросов. Очень легко согласилась бросить третий бюллетень в урну без галочки. Третий раз у пары убежал ребенок и папа с бюллетенями побежал ее догонять.

Оказалось, что на моем участке есть два военных учреждения: Военная школа поваров и в/ч 34081 - радио-хим-био-защиты. Вот эти то люди и делали нам явку. С 8-30 до 15-30 в школе постоянно находилось 100-200 военных. В сумме это было где-то на глазок человек 800.
Поварята раскололись, что их 194 срочника. А главный РХБЗшник - замполит подполковник Кукарцев оказался прошаренным: "Военная тайна! Разглашать численность военных группировок запрещено!". Тем не менее мы с ним отлично поболтали на околовоенные темы: про повышение, про то как у них хорошо, про то, где ещё хорошо. Практически устроили на службу брата наблюдательницы от ЛДПР.
Познакомились с его вопроса "Ну как? Нет нарушений? - Нет, тут все хоршо. - Это хорошо. Иначе нам бы сильно попало! Сильно-сильно!" Короче мужик! :)

Толпы солдат это, конечно, не очень приятно, но те же помощники в УИК отлично строили солдат. Иногда мне казалось, что сами они сержанты только в гражданском. Короче мужики! :-)

В основном стараниями военных в 17-00 у нас была явка 50%.

Между прочем, у нас на участке было довольно много людей, в возрасте около 30. Очень часто приходили с детьми, давали детишкам бросить бюллетени в урну. Короче, позитив!

Что касается подсчета, то было все совершенно не по законодательству. Где мог я вмешивался, но в основном не мог. Там председатель показала себя не с лучшей стороны, но в конце записала мой телефонный номер :-) Но об этом я, наверное, напишу позже.

Если оценивать УИК 1655 вцелом, то я доверяю результатам выборов на этом участке. Там выборы были честными.

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

Так вот, предупреждаю! Прямо сейчас уже начался и идет http://aichallenge.org (сходите-сходите по ссылке! там прямо на первой странице показывают пример боя)
На этот раз нужно написать мегамозг, управляющий колонией муравьев. Нужно собирать еду, воевать с другими муравьями, разрушать чужие муравейники, охранять свои.

Игровой мир на торе, набор поддерживаемых ЯП довольно большой, приятный визуализатор, ...

Первую версию бота можно сделать вообще не программируя - скачав Starter Package и засабмитив прямо его же.
Он тут же начнет играть с другими ботами и ползти вверх по турнирной таблице.

Решения будут приниматься до середины декабря.

В общем подключайтесь!

И да, я готов меняться идеями стратегий! :)

Решил рассказать о мини-проекте, который скушал часов 30-50 моего времени — о нашем пазле.



Общий сценарий разогревочной матрешки я придумал примерно за час сидя в одиночку в переговорке :)
Цель у нее была простая — заинтересовать, разогреть, и отсеять лишь совсем-совсем профнепригодных.



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

( Читать дальше... )
Для задачки, готовившейся в таком цейтноте, получилось вполне себе ничего. Собрали довольно много мелких косячков в организации, но в целом вроде ничего критичного.

Набралось довольно много людей, которым интересно, а главное которые способны решать такого плана задачи! Это очень приятно! Всем большое спасибо за участие!
Результаты тут: http://www.skbkontur.ru/career/puzzle, "суперпризы"-айпады в процессе разыгрывания.

Немного статистики:
кликов по ссылке-решению первой задачи из матрешки: чуть менее 250
переходов на финальную страничку разогревочной матрешки: почти 120
людей, приславших хоть какое-то решение на основную задачу: 35
нашедших лучшее известное нам решение: 13
на "суперприз" из них претендуют: 10 (двое прислали чуть позже окончания, а andreygubkin из Контура)

И, да! Отдельное спасибо народу из Контура, которые помогали мне придумывать, продумывать и тестировать пазл!

...попала мне в руки.



Что бы это могло значить? ;-)

Бегущий город - это ежегодное мероприятие в Екб по городскому ориентированию. Дают описание чекпоинтов - нужно по ним пройти и финишировать. Нужно взять как можно больше чекпоинтов за как можно меньшее время.

Последний раз случилось в эти выходные.

Немного статистики по нашему участию

Времени на трассе: 11 часов, 10 минут.
из них в кафешках: 2.5 часа = 1.5 часа завтрак + 1 час обед.
в общественном транспорте: 1 час, 26 минут.
на ногах, в пути, соответственно: 7 часов, 14 минут.

Пройдено пешком: 23 км.
на общественном транспорте: 18 км.
Взято чекпоинтов: 15 основных и 1 бонусный
осталось не взято: 1 основной и 1 бонусный

Соответственно, средняя скорость движения ногами: 3.2 км/ч, на транспорте: 12 км/ч

Село аккумуляторов от моего телефона с интернетом: один штатный и половина большого.


И немного истории

Мы с командой "Авось не заблудимся" в составе a_kostousov и gerasimovich_yu & \me традиционно (т.е. второй раз подряд на 50% стабильным составом) участвуем в категории Сфинкс (это пешком, и каждый чекпоинт - загадка в стиле Encounter-а). Прошлый раз заняли третье место и были довольно близки к первому. В результате в этот раз задача ставилась так: всех порвать! Получилось ли - скоро узнаем!


Немного впечатлений

Совершенно зачётное мероприятие! Плюс 100500 организаторам в карму :)
Наша стратегия осталась неизменна с прошлого года: получили очередной лист с задачами - засели на час в кафешке, половину порешали, составили маршрут и вперед дорешивать остатки на ходу. Особый кайф, конечно, когда загадки раскалываются именно на ходу, в процессе обсуждения командой!

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


Кстати, в 2010 мы пробовали участвовать в Бегущем городе в Спб, и уверенно вам заявляем - в Екатеринбурге лучше! И это вовсе не потому что заняли мы там 105 место из 137, нет-нет ;-) Просто в Екб действительно гораздо уютнее.

В общем, к чему это я все? А к тому, что вам обязательно нужно уже сейчас поставить себе напоминалку в аутлуке на через год с текстом "Обязательно поучаствовать в БГЕ 2012" :)

( Под катом фотки! )

...продожение! Начало тут: Часть 1

Итак, лишь вечером в субботу у нас появился первый конкурентноспособный бот: он перебирал вражеские слоты с 255 до 0 в цикле и мочил каждую ячейку тараном до тех пор, пока она не умрет. На вынос одной беззащитной ячейки уходило ~30 ходов. Это был фейл. Если бы мы сразу подумали головой, то не стали бы браться за такой подход вообще - слишком уж он слабенький.

По результатам первых боев стало понятно, что это никуда ни годный бот. Поскольку эмулятор все ещё не содержал логику зомби, мы решили, что все дело в них. Андрей сел делать зомби, а я тесты к этой логике.

Эмулятор эмулятором, а нужно этими зобмями как-то пользоваться. Решили, что самое удачное - собрать зомби, который с помощью help(0 0 много) просто убьет слот номер ноль. А это должен быть очень важный слот, ибо он удобен для формул. Осталось выбрать константу "много". Не долго думая, мы создали целых трех зомби: первый мочил на 2.1*8192, второй на 2.1*16384, третий на 2.1*32768. Выбор зомби производился в момент пуска, глядя на жизнь вражеского слота 0. С таким подходом зомби выносили слот 0 гарантированно. Вообще-то это был ещё один фейл. Гораздо круче было бы засадить зомби делающего что-то в цикле так, чтобы страдало более одной ячейки. Но что сделали то сделали. Кстати, такую фичу мы так и не сделали до конца контеста.

Был конец субботы, когда мы засабмитили зомби-бота. К тому времени в логах на сервере нас уже успели несколько раз убить за менее 1000 ходов. Это, мягко говоря, стимулировало мозговую деятельность. Стало понятно, что правильная нападательная стратегия скорее связана с картами help и attack, чем с картой dec.

Стало понятно, что как минимум, надо уметь лечить свои ячейки. Андрей к тому времени уже начал чувствовать и разбираться в этих ваших комбинаторах. Мы обсудили как делать лечилку и разошлись. У Андрея была домашняя задача - сделать лечилку. У меня - принять у студентов экзамен по ООП.

В 15-00 воскресенья я разобрался с экзаменом. В это время наш бот успешно лечил свой 0-слот. Надо было делать атакера из этого слота. Андрей занялся уберхиллером - хиллером, который постоянно поддерживал максимум жизни во всех жизненноважных для бота ячейках. Я занялся атакером из своего 0-слота.

Чтобы вы оценили, код создания аттакера в ячейке выглядел так:

var damage            = string.Format("get ({0})", damageSlot);
var dellayedGetTarget = DelayApplication("get", targetSlot, false, false);
var attack_I_I        = DelayApplication("attack (zero)", dellayedGetTarget, false, true);
var attack_I_I_D      = DelayApplication(attack_I_I, damage, true, false);
var value             = Form.AddSelfReproducing(slotNo, attack_I_I_D);
return ThePlan.MakePlan(slotNo, value);

То есть мы начали растить второй уровень абстракции - вводить примитивы вроде AddSelfReproducing, DelayApplication. Позже появятся AddCycling, Repeat(form, N), Sequence(form1, form2), AddIncLoop (цикл с увеличивающимся аргументом).

Отправить такого бота мы смогли лишь в 21-00. К слову, там был применен ещё и такой хитрый прием: атаковать врага мы начинали не с 255 ячейки, а пропустив 8 ячеек, с 247-ой. Это было сделано для обхода тупых соперников, которые будут постоянно лечить 255-ую ячейку, ожидая сильную атаку на нее. Даже не знаю, на сколько эта военная хитрость помогла, но она у нас сохранилась до самого конца.

После этого мы, конечно, сами добавили агрессивное лечение своей 255-ой ячейки надеясь на то, что все остальные боты нормальные и атаковать будут именно с 255-ой. Другими словами, наш бот представлял собой того самого тупого бота, защищающего только 255-ую. :) Вообще в нашем боте всю игру был сильный перекос в сторону нападения.

Следующим нашим шагом было выкидывание лишних зомби (они инициализировались тупо дольше, чем нас убивали), оставили лишь одного. А потом ещё и начали создавать атакера, зомби и 255-лечилку лениво лишь после создания основного лекаря.

А вот потом случилось самое забавное. Мы запустили бота на эмуляторе жюри и увидели крайне странное поведение. Логгирование, отладка и голова на плечах помогли понять - их эмулятор обрывает циклы чуть раньше нашего.
Времени было около 2-х часов ночи (4 часа до окончания контеста) когда мы сели ловить баг в нашем эмуляторе. Часа через полтора, написав несколько тестов, перечитав комменты в официальном блоге, и поспорив друг с другом причина была обнаружена и однозначно идентифицирована: баг в эмуляторе жюри. 8) Если подробнее (и серьезнее), то при применении S, за аппликации считалось и то, что реально аппликацией не является.
Например, S(S)(S)(I) по мнению жюри вычисляется в 4 аппликации вот в такой последовательности:
1: S(I)(S(I))
2: S(I)(S(I))
3: S(I)(S(I))
4: S(I)(S(I))
Да, именно - четыре одинаковые строчки :) А по моему мнению тут всего одна аппликация. В версии организаторов, конечно, тоже есть своя логика, но... :) В общем +одна строка кода и все стало совпадать.

Оставалось 2 часа до окончания в тот момент, когда мы засабмитили решение с этим фиксом + с жалкой попыткой оживлять и лечить нулевую ячейку, если вдруг ее убили каким-нибудь мерзким зомби. Делать что-то ещё было поздно, хотелось спать и вообще. Так все и закончилось для нас.


Сейчас на неофициальном сервере статистика такая: 578 игр, 361 побед. Это 62% побед, что как бы мягко намекает, что во второй тур мы не проберемся :)

В целом, у нас получилась очень удобная инфраструктура для реализации стратегий - опыт пром-программирования дает о себе знать. Нам бы ещё стратега в команду, мы бы всех точно порвали - я гарантирую это! :)

Вообще, в команде из 2х человек хоть и комфортно играть, но рабочих рук сильно не хватает. Ещё один-два человека было бы очень кстати.

Ну и немножко статистики из репозитория:

2009, 60 коммитов, 50 файлов, 147 K кода
Sapka, 228 коммитов, 62 файла, 125 K кода
2010, 61 коммит, 37 файлов, 101 K кода
2011, 42 коммита, 12 файлов, 53 K кода