Category: лытдыбр

Category was added automatically. Read all entries about "лытдыбр".

Я понесу огонь в самой масштабной эстафете в истории Олимпиады

Я буду участвовать в эстафете Олимпийского огня в Санкт-Петербурге. Это событие произойдет в ближайшее воскресенье, 27 Октября 2013 года в 15:37. Мой участок в 300 метров будет начинаться по адресу наб. Макарова 18 и заканчиваться у дома номер 20. Спасибо всем за поддержку меня в конкурсе на участие в Олимпийский эстафете!

Я буду рад видеть и приветствовать всех, кто придет посмотреть.

UPDATE: Это было супер!
Передача огня Несу огонь!

JavaOne Moscow 2013

На этой неделе я побывал в Москве на JavaOne Moscow 2013. Сделал доклад "Миллионы котировок в секунду на чистой Java" аналогичный своему выступлению в Санкт-Петерурге на JUG. Однако, здесь был всего час времени и доклад получился урезанный по содержанию по сравнению с предыдущим. Надо сказать, что я планировал урезать доклад "по глубине" (то есть не вдаваться глубоко в подробности и лирику, а пробежаться по верхам), но не получилось. Это, в общем, побочный эффект того, что для этого доклада я готовил презентацию в том стиле, когда презентация не содержит дословный текст и содержимое рассказа, а лишь подчеркивает основные мысли, которые хочется донести до аудитории (крупным текстом), в то время как основное пояснение дается голосом.

Конференция продолжалась два дня, но я на неё приехал всего на один день, 24 Апреля, когда был назначен мой доклад и успел послушать не много других докладов. Больше всего мне понравился доклад "Пуленепробиваемый Параллелизм Java", сделанный Алексеем Шипилёвым shipilev. Он рассказал и показал на конкретным примерах ошибки связанные с многопоточностью, которые обнаруживаются в JVM, JDK и в железе. Поделился методологией, которую они используют для написания тестов на поведение кода при одновременной работе множества потоков, чтобы проверять весь стек на соответветсвие модели памяти Java (JMM). Обещал, что написанный каркас для разработки аналогичных тестов будет открыт.

Стоит упомянуть и доклад "Exploring JavaFX 3D", сделанный Джеймсом Уивером. Он показал рабочие примеры кода для вывода 3D-графики, которая появится в следующей версии JavaFX, которая выйдет в составе JDK 8. Джеймс говорил медленно, боясь что аудитория его не поймет. Однако доклад был в достаточной мере насыщен демонстарциями работающего кода, чтобы быть не скучным. У команды JavaFX получается вполне элегантный, мощный и достаточно производительный API для обогащения интерфейса приложений 3D графикой.

Лытдыбр: Выбирая билеты в Москву я не обратил внимание на место проведения конференции. Я привык что в Москве мне всегда нужно в центр, а Аэроэкспресс с любого аэропорта приезжает в центр на кольцевую линию метро, откуда быстро можно попасть в любое центральное место, и не важно в какой аэропорт ты прилетел. Более того, из-за Московских пробок Аэроэкспресс+Метро почти всегда быстрей такси. Я привычно выбрал Домодедово в том числе из-за того, что там ближе всего идти до станции Аэроэкспресса, хотя его перегруженность людьми уже стала напрягать. Уже в аэропорту Пулково я посмотрел на место проводения конференции и на карту Москвы, и осознал, что конференция проходит в Крокус Экспо, сразу за МКАД-ом, и симметричность относительно разных аэропортов жестко нарушается. Если бы я полетел через Шереметьево, то сэкономил бы на дороге туда и обратно не меньше часа времени, взяв такси.

[topcoder] SRM 252 & 253

Быстро пролетели topcoder SRM 252 и SRM 253. Кратко опишу происходящие события.

На SRS 253 я конкретно отстоялся. На второй задачке я завалился выйдя за предел времени выполнения. Когда прикидывал в голове количество операций, то забыл один нолик. В итоге получилась программа на 10M неочевидных операций, а в 2 секунды это уже не укладывается. Обидно еще и то, что последний тест из примера задачи был как раз на время исполнения, и я пользовался ExampleBuilder-ом, то есть прогонял свое решение на всех тестах. Однако в спешке я не заметил, что последний тест у меня не завершается. А задачка ведь была стандартная и я массу таких прорешал за свою жизнь... А последнюю задачу я просто не смог решать за оставшееся время – не догадался во время соревнования до грамотного подхода (считать отдельно количество путей и мат. ожидание количества очков). Результаты SRM 252 были отменены из-за технических накладок и это мне оказалось на руку.

На SRM 253 я начал очень хорошо – быстро решил все задачи и к окончанию кодирования был на первом месте в своей комнате и на седьмом месте в общем зачете. Однако во время challenge phase меня вывели на чистую воду. В третьей задачке (которую я решал аналитически найдя седловую точку) я не учел граничные случаи когда седловая точка имеет допустимое значение (от 0 до 1) для одного значения вероятности и недопустимое значение (меньше 0 или больше 1) для другого. Было очень поучительно и интересно, так как задачку такого типа мне еще никогда до этого не приходилось решать. В итоге 4-ое место в комнате и 24-ое в общем зачете. Но рейтинг у меня все равно вырос (хоть и чуть-чуть).

P.S. Написал свой собственный plug-in для тестирования Java задач на основе ExampleBuilder. Его легко приспособить для C#, но не для C++, так как используется Reflection по аналогии с JUnit. Он мерит время работы каждого теста и позволяет легко переключатся с запуска всех тестов, к запуску только одного (без необходимости комментировать лишние тесты), что удобно для отладки. Доведу до ума (попробую на очередном SRM) и выложу. Кому-нибудь нужно?

[topcoder SRM 250] В меру сложно и разнообразно

В общем и целом, topcoder SRM 250 оказался интересным и в меру сложным ;) А сдал решение последней задачки буквально за 5 минут до окончания. Чудом решив все задачи правильно я оказался на 6-м месте в общей таблице результатов, что сильно подняло мой рейтинг (до 2215).

Первая задачка была простой, но с подковыркой. Я был уверен, что решение в double-ах пройдет, но, признаюсь, не сильно напрягал голову когда выбирал 1e-9 в качестве эпсилона. К счастью, этого было достаточно.

Над второй задачкой пришлось подумать. Быстро отбросив идеи про жадный алгоритм (не зря я перечитывал теорию матроидов) я придуман динамический алгоритм и приступил к написанию кода. Однако трудность меня подстерегала при вводе данных. Я стал дико тупить и минут 5 не мог сообразить что означает AM/PM нотация для времени. Пытался тщетно сообразить что же именно значит 12:35PM и 12:35AM. Эти потуги происходили когда я уже набил код для разбора строчек вида hh:mmaa самостоятельно. У меня уже было целое число от 1 до 12 обозначающее час, целое число от 0 до 59 обозначающее минуты и флаг AM/PM. Уверенность что я что-то понял у меня так и не появилась, и я удалил написанный код парсинга, поручив всю работу стандартным классам в Java: calendar.setDate(new SimpleDateFormat(“hh:mmaa”).parse(s)). А дальше – calendar.get(Calendar.HOUR_OF_DAY) и calendar.get(Calendar.MINUTE).

Третья задачка была чистой геометрией. Здесь всё было в технике и аккуратности кодирования. На первом этапе надо было найти все точки результирующего многоугольника. Написав этот код, мне пришлось его отлаживать (было несколько опечаток в математике пересечений). Когда отладка была закончена, и у меня был правильный список точек, я просто скопировал свое решение задачки из предыдущего соревнования, которое находит площадь выпуклой оболочки. В первой части решения (ввод данных и нахождение пересечений) я слишком активно пользовался cut-and-paste-ом. Если бы я программировал более структурно (завел бы класс Polygon с методами чтения и проверки точки на принадлежность), то это бы сильно упростило и ускорило бы процесс отладки.