Pull to refresh
176.11
JUG Ru Group
Конференции для Senior-разработчиков

О чём молчит Joker. Рассказ-история о конференции

Reading time 15 min
Views 23K
15 октября славный город Санкт-Петербург посетил суперзлодей Вселенной Joker.
Нет, он никого не убил, и ни один Бэтмен не пострадал. Но его посещение, тем не менее, запомнится многим. Во-первых, это была премьера новой конференции по Java технологиям. Во-вторых, эта конференция удалась на славу, а значит, её ждёт большое будущее, а первая конференция – всегда история.

image

Приятная неожиданность


Я выступал на конференции в качестве докладчика: организаторы обратились ко мне за два месяца до и предложили выступить, что было приятной неожиданностью. Организовали ее лидеры Питерского JUG – Алексей Федоров (@23derevo), Андрей Дмитриев(@real_ales) и Иван Долгов (@jetliner) (и еще много кто помогал). На одном из афтепати Алексей рассказал, как ему пришла идея названия конференции: «Послушал, — говорит, — в Мариинке „Любовь к трём апельсинам“ Прокофьева, а потом долго уснуть не мог. В голове крутились разные её персонажи: король пик, король треф, шут. А дедлайн по концепции новой конференции был уже на носу. Так и возникла идея как-то обыграть тему с игральными картами. Ну а поскольку Java-конференции обычно называются как-нибудь на букву J, то слово Joker пришло как-то само собой».

И тем более удивительно, что за два месяца ребята умудрились сделать очень приличную программу, работая со всеми спикерами индивидуально, делая прогоны и всячески помогая. Но не обошлось в программе и без курьезов: три названия докладов начинались с “ О чём молчит …”.
Как так получилось, эта история умалчивает.

Проживание


От нашей компании Excelsior на конференции выступало два человека: я и Павел Павлов (@noinline). Проходила конференция на Васильевском острове, в гостинице “Прибалтийская”. Выйдя из метро, мы решили дойти до гостиницы пешком – нам показалась хорошей идея прогуляться по ночному Питеру. Но пройдя метров 10-ть, мы вдруг обнаружили себя в городе Новосибирске: до боли знакомая советская застройка и погода точь-в-точь, как в Новосибирске. “3-я улица Строителей", короче.

Практически все приезжие спикеры и организаторы жили в одной гостинице, и так как конференция тоже проходила в гостинице, то можно было ходить на доклады в тапочках. И это было чудо какое-то, я в первый раз с таким столкнулся: просыпаешься утром, идешь завтракать, встречаешь кучу знакомого народа, общаешься, пока не начнут выгонять на обед, потом поднимаешься на второй этаж – а вот и конференция, потом афтепати, а потом возвращаешься в гостиницу, а там афтеафтепати. Короче наобщался на программистские темы так, как никогда в жизни, даже устал от этого в конце вусмерть!

Конференция


И поднявшись на второй этаж, я оказался на конференции. Встретив организаторов с опухшими глазами, я сразу понял, кто сегодня “герои нашего времени": без вопросов можно было догадаться, что команда почти не спала последние несколько дней.
Открытие конференции осталось практически не замеченным, Лёша Фёдоров сообщил, где находятся какие залы (помеченные мастями карт – надо же стиль выдерживать), по которым все и разошлись. В коридоре можно было пофотографироваться с Джокером (см. фото выше) и поиграть в древние компьютерные игры.



«Как я создал desktop-приложение на Java, скачанное 9 000 000 раз»


Я пошел на доклад Антона Кекса (@antonkeks), автора нашумевшего доклада на JUG.ru "Как нам спасти Java”. Антон занимается на основной работе “кровавым энтерпрайзом» (термин, подхваченный мной на этой конференции), а в свободное от работы время делает популярное десктопное приложение для прослушки сетки “Angry IP scan”, которое изначально Антон написал на С, а потом переписал на Java, чему он очень рад.



Начался доклад с небольшого факапа: все доклады шли с компьютеров организаторов и на этих компьютерах не стояла Java! В результате Антон не смог показать своё приложение в действии. Этот факт еще раз убедил меня в том, что, если вы делаете десктопные приложения на Java, нельзя полагаться на то, что у конечного пользователя эта Java стоит (о том как решить эту проблему, был мой доклад “Java худеет” на JavaOne в Москве). Но, к сожалению, это не убедило Антона.

Весь доклад Антон пытался донести до людей простую мысль, что делать на Java десктопные приложения можно и нужно! С чем я полностью согласен, меня до сих пор искренне удивляет факт, почему Java на десктопе не очень популярна, особенно при растущей популярности Mac и Ubuntu. Последний факт подтолкнул Антона переписать приложение с С и Win API на Java, просто потому что он сам Windows уже давно не пользуется, но и терять Windows пользователей ему не хочется.

В качестве UI для Java, Антон пропагандировал SWT. Если кто не знает – это UI библиотека от IBM на базе которой сделан UI Эклипса. Прикол этой библиотеки состоит в том, что приложения, написанные на SWT всегда выглядят как родные приложения целевой платформы, просто потому, что используют родные контролы для отрисовки UI. Что не так с дефолтным UI для Java – Swing, где UI целевой платформы эмулируется (и не всегда хорошо). Вообще войны Swing vs. SWT были довольны популярны в начале 2000-х. Моя личная позиция по этому поводу, что оба UI – хороши, и если на SWT ты всегда получишь родной UI целевой платформы, то на Swing ты можешь сделать UI лучше, чем родной и пример этому IntelliJ IDEA (я не считаю, что Windows так уж хорошо рисует кнопочки-окошки). И в свете последнего утверждения, выбор JavaFX я тоже не считаю плохим.

Еще Антон рассказал про HIG – human interface guidelines. Идея этой штуки состоит в том, что на разных платформах есть свои правила расстановки/именования контролов, и лучше этим правилам следовать, чтобы конечный пользователь получал привычный для себя опыт при работе с вашим приложением. И таким образом HIG правила конкретной платформы нужно учитывать при написании UI. Да, будет немного платформенно зависимого кода, но разными трюками (типа layout manager), как утверждает Антон, можно количество этого кода сделать очень небольшим.

После доклада мы с Антоном еще минут 20 проговорили в коридоре: я очень рад знакомству с ним, и наверное, он для меня – одно из самых ярких событий этой конференции.

Project Jigsaw. New fail


На кофе-брейке я встретил Шуру Ильина (@shurymury) – он на этой конференции делал доклад “Project Jigsaw. Take 2”. Я был очень рад встречи с ним и по-дружески спросил его: «Ну как, готов к докладу?”. На что он меня огорошил: ”Конечно готов, ведь весь мой доклад будет нести одну простую мысль: ПФУ! ». Я говорю: “Не понял, что значит ПФУ? ". Шура: “А то и значит – не будет никакого Jigsaw, ПФУ! Точней не будет публичной модульной системы Java”. Я – в ауте! Шура: “Представляешь, я специально поехал на JavaOne, чтобы послушать Марка (Реинхольда) про Jigsaw, чтобы сделать этот доклад, и он там заявляет, что мы решили не выпускать модульную систему, потому что она никому не нужна и спрашивает в зал «кому- нибудь здесь нужна модульная система?» … — и полный зал рук!”. В итоге, как потом рассказывали, Шура весь свой доклад уложил в 15 минут, чем многих разочаровал. Но поверьте, он разочарован не меньше! Как и я.

Остается только догадываться, что на этот раз произошло с проектом, но я надеюсь, что Java комьюнити не оставит этого просто так и у нас все-таки будет стандартная модульная система в Java.

Понимание процесса сборки мусора и что вы можете делать с этим


Потом я пошел на полуторачасовой доклад CTO и Co-founder Azul Systems – Gil Tene. Это был шикарный доклад – очень рекомендую. Если кто не знает, компания Azul начала с производства своих многопроцессорных компьютеров Vega, где каждый процессор с 54 ядрами на борту и воткнуть в такую машину можно терабайт оперативной памяти. И для этих компьютеров они сделали специализированную JVM: им пришлось решать задачу масштабирования своей JVM на огромном количестве процессоров и памяти. Научившись делать GC, способный масштабироваться на огромных объемах памяти, Azul решил дать счастье всем и выпустил JVM под названием Azul Zing. Эта JVM унаследована от HotSpot (там только MM и GC свои), поэтому она работает на том же железе, что и HotSpot.

Гил очень подробно и доступно рассказал про сборку мусора в Java, начиная с азов и кончая самыми навороченными техниками, освежив в моей памяти все, что я знал о GC. Чем сослужил мне хорошую службу, потому что через пару дней мне тоже надо было рассказывать на JUG про GC уже в нашей JVM – Excelsior JET. Кстати, меня очень поразило, как Azul GC похож на наш, по крайней мере, чисто внешне: он собран из тех же кирпичиков, но пришли мы к этому независимо.



Основная идея, которую пытался донести Гил, – в процессе сборки мусора еще далеко не поставлена точка и тот набор GC, что есть у ХотСпота, далек от идеала. В результате чего обычному Java разработчику нужно знать миллион ручек для настройки GC, чтобы решить свои проблемы с управлением памятью в Java. По его мнению, ручка должна быть ровна одна: –Xmx (мы пошли еще дальше, и в нашем GC даже эта ручка не нужна). И вместо того, чтобы прятать голову в песок и говорить, что в Java нет проблем с управлением памятью, можно попытаться посмотреть на мир Java шире и обнаружить, что существуют другие реализации JVM, в которых, возможно, ваши проблемы управления памятью решены лучше.

Мне кажется, это был самый сильный доклад на конференции, поэтому крайне удивительно, что он не попал в топ 10 докладов по оценкам зрителей, при том, что в этот топ попал доклад про раскладку полей в объектах HotSpot. Складывается ощущение, что народ крайне настороженно относится к альтернативным реализациям Java. Но почему? Ведь это большое счастье, что Java позволяет делать альтернативные реализации и при этом гарантирует, что ваше приложение будет работать на любой совместимой с Java реализации. И эти реализации могут решать проблемы, до которых у Oracle никогда в жизни руки не дойдут.

После доклада, я успел пообщаться с Гилом: мы поговорили про наши GC. Я был приятно удивлен, что он про нас прекрасно знает. Вообще, разработчики любых JVM в мире, как правило, про нас знают, чего нельзя сказать, к сожалению, про Java разработчиков.

Занимательные истории из жизни технической поддержки JVM


После обеда (очень хорошего, кстати), пришла очередь выступить и мне: мы с Мишей Быковым из Oracle делали совместный доклад. Идея доклада у нас родилась еще в январе. Время прохождения конференции удачно совпало со временем отпуска Миши, который он решил провести в Европе и России (сам он живет в США). Миша работает в Oracle Java Licensee Engineering и некоторое время назад был нашим официальным выделенным инженером технической поддержки от Oracle, реально помогая нам проходить тесты JCK. Кроме того, он занимается техподдержкой крупных клиентов Oracle. У нас в Excelsior тоже есть техподдержка и в ней дежурят по очереди все разработчики JVM, включая меня. У нас с Мишей за годы накопилось довольно много интересных и забавных случаев из жизни техподдержки, и мы решили поделиться ими с миром. Мы разбили доклад на четыре части наиболее частых и типичных проблем из техподдержки и разбавили их веселыми историями. Нам хотелось сделать доклад развлекательным, и, мне кажется, у нас получилось: было весело, народ смеялся.



Scala для профессионалов


От нашей компании был ещё доклад про Scala, который делал Паша Павлов.

Несколько лет назад мы решили переписать ядро нашей JVM практически полностью. Одна из существенных компонент нашей JVM, отличающая ее от других JVM – это AOT компилятор, то есть компилятор, который порождает оптимизированный машинный код до исполнения программы (получаются “честные exe”). AOT компилятор мы решили переписать на Scala, и знаете, у нас получилось! Поэтому изначально мы хотели сделать доклад “Java in Scala” (в противовес Java in Java довольно известного проекта Graal от Oracle Labs – это попытка переписать HotSpot JIT на Java), в котором хотели описать наш опыт применения Scala в таком довольно непростом проекте. Но на голосовании здесь, на хабре, доклад не оказался столь популярным, и организаторы попросили поменять тему на более общую, но про Scala. В итоге у Паши было всего 2.5 недели, чтобы приготовить доклад. И он его готовил вплоть до самого выступления! Единственный прогон он успел сделать в аэропорту среди объявлений “Пассажир Иванов, срочно пройдите на посадку". Это конечно все сказалось на выступлении, но меня радует, что Паша все таки донёс до людей свою основную мысль, что Scala – это не просто лучшая Javа, а самостоятельный язык со своей идеологией и с большим будущим. Посреди доклада произошел забавный эпизод: в тот момент когда Паша назвал лямбды в Java 8 «дешёвой китайской имитацией», Лёша Шипилёв (@TheShade) отправил такой твит:



Спорим, в твоем приложении есть утечка памяти?


Когда этот доклад появился на голосовании на Хабре и неожиданно стал лидером, многих удивила его тема: как так, в Java вроде есть сборка мусора, и, таким образом, утечки памяти в принципе невозможны. Но меня эта тема ничуть не удивила: я в своей жизни столько этих утечек видел на примере наших клиентов!

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

Многие популярные Java фреймворки имеют внутренние кэши (которые часто устроены как хэш-таблицы) и, не зная этого, вы можете на ровном месте получить утечку памяти. Доклад Никиты Сальникова-Терновского как раз и состоял в том, что, если вы забудете в таком-то фреймворке вот это дёрнуть, то получите утечку (откуда вы должны это знать – непонятно).

Особенно интересным оказался случай с ThreadLocal. Никита утверждал, что если вы заведете глобал типа ThreadLocal в своем веб приложении, а потом это веб приложение передеплоите (без перезапуска сервера), то вы гарантировано получите утечку. Этот случай мы потом подробно разобрали на афтепати с участием Лёши Шипилёва и обнаружили, что в реализации ThreadLocal в Java API есть баг! Потом мы нащупали пути как это полечить, и Лёша пообещал этот баг зарепортовать.

О чём молчат Heap Dump-ы


Идею этого доклада я услышал от Лёши Шипилёва еще на JavaOne в Москве. Он сказал, что устал читать на хабре разные посты про то, как правильно раскладывать поля в своих Java объектах, и что он хочет сделать доклад, как поля раскладывает HotSpot. В принципе, любая Javа реализация оптимизирует раскладку полей в объекте из соображений выравнивания, поведения кэша процессора и минимизации размера объекта. Поэтому порядок полей, который вы задаете в своих классах, не значит вообще ничего: для JVM – это просто набор полей, которые она вольна упорядочить, как ей вздумается (и на разных JVM, и даже на разных версиях одной и той же JVM – этот порядок может быть разным). Поэтому нет ничего более глупого в Java программировании, как пытаться что-то оптимизировать в порядке полей на уровне исходных текстов. Но тогда в Москве меня удивило, как из того, что я вам тут рассказал в двух предложениях, можно сделать целый доклад. Но Лёша справился (не без помощи Баруха (@jbaruch), правда, который держал микрофон в конце доклада, когда у Лёши сдох его hands free микрофон)!



В конце позабавила реакция выходивших слушателей: «представляешь, у них там в объектах поля могут располагаться совсем не так!» И в который раз меня удивило, почему люди с такой охотой идут слушать доклады про специфические внутренности JVM.

Афтепати


У конференции было два афтепати, один неофициальный, который был в конце первого дня, и официальный: после unconference. В первый день в одном углу расположились разработчики разных JVM, в другом – мастера Java EE. А посередине сидел Шура Ильин, который в разгаре вечеринки завопил: «так, здесь JVM хардкор, там кровавый Enterprise, а я что здесь делаю!».

Так как афтепати был на другом берегу Невы, то тем, кто жил в гостинице, нужно было успеть попасть туда до развода мостов. Все это делали по-разному. Я уехал довольно рано, кто-то попал на «трёхчасовое» сведение, а некоторые и на него не успели, и в результате гуляли по Питеру до шести утра и вернулись в гостиницу утром. Поэтому на следующий день на Unconference кое-кто не смог присутствовать.

Unconference


Что такое Unconference не знал никто из тех, кто туда собирался. Накануне всем спикерам выдали два приглашения на мероприятие: одно для себя и второе спикер мог дать любому слушателю первого дня. И конечно же, большинство спикеров забыли про это приглашение, я, правда, в конце первого дня вспомнил и кому-то вручил.

В начале Unconference Саша Белокрылов (@alexbel) объявил формат: событие делится на три смысловые части: круглые столы, где обсуждаются какие-то темы – их заявляют любые желающие и за какие темы больше проголосуют участники, те темы и обсуждаются; lightning talks – 5 минутные доклады на любую тему; “вбросы из зала” – в урну можно вбросить бумажку с любым вопросом и потом всей толпой на эти вопросы отвечают.



Первоначально, не зная точного формата мероприятия, я думал выступить с темой «Веб 3.0”, которую в прошлом году озвучил на DevDay в Новосибирске. Этот доклад по формату не лезет ни в какую конференцию, и я подумал, что для Unconference это будет в самый раз. Но к моему удивлению, доклад не подходил и к объявленному формату: доклад длится несколько больше чем 5 минут. Я попросил собравшихся дать мне 20 минут: было начало, мало кто соображал, что происходит и все согласились. Так сказать, пустили на разогрев.

Если вкратце, то идея, которую я озвучил, состоит в следующем. Я хочу добавить в Java-платформу еще одну модель распространения приложений, в которой приложение прилетает из сети по частям и по запросу, и первым прилетает из сети представление (пользовательский интерфейс). То есть я хочу устроить распространение клиентских Java приложений по типу Web приложений. Но это не Java WebStart (и не апплеты), где приложение загружается из сети целиком. В моей модели приложения будут прилетать на клиент мгновенно, как в вебе, при этом могут быть произвольно сложными, как на десктопе. И, что тоже немаловажно, писать такие приложения можно на любых JVM-языках, от JavaScript до Scala.

В принципе, такая технология может составить конкуренцию классическому вебу, основанному на HTML+JavaScript. Она включает в себя классический веб, при этом даёт программисту возможности, которые веб в сегодняшнем состоянии не способен дать и непонятно, когда будет способен. Поэтому я ее позиционировал как Веб 3.0. Но на Joker, я окончательно понял, что правильней эту технологию позиционировать как Десктоп 2.0, потому что веб разработчики принимают эту идею в штыки и им мне ее не продать никогда.

После меня выступал Gil Tene, который пожаловался, что я говорил по-русски. Он еще раз напомнил, что в сборке мусора у Java есть много проблем, которые на самом деле challenges и что не надо прятать голову в песок, а надо решать проблемы.

Далее еще была пачка докладов, из которых я мало что запомнил. А перед обедом мы разбирали “вбросы из зала”. Из запомнившегося: “Есть ли у Java техподдержка?”, “Java превращается в С++?», «Как мне закомитать фикс в OpenJDK?”, „Нужно ли в Java столько же тестов, сколько для динамических языков?”, “Можно ли статическим анализом ловить ошибки?».

После обеда мы собирались в кружки. Я заявил тему «Будущее Java в RIA и Mobile”, которая благополучно набрала необходимое количество голосов. Но, к сожалению, дискуссия переросла во флейм: в ней принял участие Виктор Полищук, один из спикеров конференции, который отстаивал точку зрения, что Веб сегодня очень хорош для написания клиентских приложений, мало того, он быстро развивается, и что Java в client-side просто не нужна. Я отстаивал прямо противоположную точку зрения: сложность задач в вебе стремительно растет (на клиентской стороне), и что через некоторое время текущими технологиями, основанными на HTML + JavaScript эти задачи будет решать слишком дорого, потому что в веб-технологиях есть встроенные от рождения проблемы, которые не решаются естественным путем. Потом к дискуссии подключился Саша Белокрылов, который сказал, что, начиная с некоторого барьера сложности, приложения в вебе писать нецелесообразно, а правильней их делать в десктопе (чем в общем-то поддержал мою точку зрения, не зная того), и чтобы иметь WORA (write once run anywhere), надо их писать на Java. Но Витя с этим упорно не соглашался и на вопрос „Можно ли написать Photoshop в веб технологиях, чтобы это еще работало удобно и быстро?“, не задумываясь, ответил – “ Можно!”.

Обсуждали также mobile. Я поделился болью многих mobile разработчиков: написав приложение под одну мобильную платформу, на другую ее приходиться практически заново переписывать. В итоге все развлекаются как могут: кто-то пишет на С, кто-то развлекается с JavaScript. И мое мнение, что как раз Java здесь обязана прийти на помощь, предоставив более высокий уровень (по сравнению с С) и хорошую производительность (по сравнению с JavaScript). Присутствующие высказали сомнение, что Java может появиться на iOS, потому что там не возможен JIT (по iOS политике). На что я рассказал про Excelsior JET, который умеет статически компилировать Java в машинный код, оставаясь при этом совместимым с Java, и что у нас есть планы сделать решение для iOS. Чем удивил собравшихся: про нас даже спикеры, как выяснилось, редко знают.

Ещё я принял участие в дискуссии про OpenJDK. Обсуждались темы, что простому смертному крайне сложно что-то закомитать в OpenJDK и что у инженеров Oracle здесь есть очевидное преимущество. Я в свою очередь пожаловался, что мы в своей реализации нашли и пофиксали довольно много багов в Java-платформе и что мы бы с удовольствием эти фиксы пожертвовали бы в OpenJDK, но у нас тогда могут возникнуть лицензионные проблемы: наш код будет выпущен под GNU лицензией и неочевидно, можем ли мы использовать наш же код в нашей коммерческой лицензии для Java.

Афтепати 2


Второе афтепати было недалеко от гостиницы, соответственно, в этот раз у людей, проживающих в гостинице, не было проблем с разведением мостов. Мы, JVM-щики, опять скучковались, чем, правда, ввергли на этот раз в уныние Кирка Пеппердайна: нам было крайне сложно обсуждать проблемы JVM на английском (не хватало лексики) и мы их обсуждали на русском.



После афтепати, случилось еще афтеафтепати с Виктором Полищуком в гостинице. Мы сцепились языками на тему Java vs. JavaScript. Мое мнение здесь состоит в том, что писать большие системы на JavaScript – это неэкологично: этот язык создавался для другой цели. Кроме, того зная про виртуальные среды исполнения не понаслышке (все таки 16 лет опыта изготовления JVM), я могу себе представить, какой это ад – оптимизировать JavaScript в практически полном отсутствии типовой информации. Но в итоге, Вите удалось меня убедить, что соблюдая некоторые дисциплины программирования на JavaScript (например, используя JSDoc и инструменты проверяющие статические ограничения на входные параметры, кстати, их кто-нибудь использует?), большие системы на JavaScript можно писать. Мне в свою очередь удалось убедить Витю, что у JavaScript есть проблемы с производительностью. По окончанию этого разговора, у меня родилось желание написать тотальную статью Java vs. JavaScript: у людей есть очевидное недопонимание природы этих явлений. Но писать я ее буду долго.

JUG: Excelsior JET в действии


На следующий день, не смотря на то, что конференция Joker официально закончилась, она не закончилась для нас с Пашей Павловым. В этот день мы с ним выступали на питерском JUGе и рассказывали про Excelsior JET. На питерском JUG мне предложили выступить ещё на JavaOne в Москве. Мы предварительно договорились на осень, но осенью JUG решил провести Joker. Но чтобы, как говорится, два раза не вставать, мы решили выступить и на JUG тоже.



Но готовились-то мы к конференции, и поэтому к выступлению на JUG у нас не было физической возможности приготовиться. В итоге, мы как настоящие профессионалы, дорисовывали слайды в маршрутке по пути в офис Oracle, в котором проходила встреча. Придя в офис, выяснилось, что организаторы не ожидали, что мы собираемся докладывать со своего ноутбука: мы действительно собирались показывать Excelsior JET в действии, и ставить его на ноутбук организаторов не хотелось. Но им было нужно устроить видео захват экрана ноутбука, а для этого нужна была специальная программа, которая, к несчастью, требовала .NET 4.0. Выяснилось, что это чудо в перьях весит больше 200 мегабайт и ставится очень долго. Из-за этого начало доклада отодвинулось, и хорошо пришёл на помощь Лёша Шипилёв, который сказал, что видео захват умеет делать VLC – и ей не нужен .NET. Мы быстро установили VLC и начали доклад. А хваленый .NET ставился потом ещё почти час и не давал себя убить, чем местами мешал презентации. Зачем я это так долго рассказываю: кто будет смотреть видео, может не понять без этого контекста шуток про .NET.

Вообще Excelsior JET, по своей кодовой базе является самой древней JVM в мире: там до сих пор осталось довольно много кода, который был написан до появления Java. Но мы впервые публично рассказывали про него так подробно.

Доклад, который был экспромтом почти полностью, в итоге длился 3.5 часа, и что меня удивило, народ внимательно нас слушал и не уходил! Но ближе к концу я уже настолько устал, что еле мог связать два слова, особенно когда рассказывал про рантайм. На самый конец у нас был бонус-трек: компиляторный хардкор. Паша Павлов рассказывал про SSA Regalloc, который был изобретен в 2005 году (что по академическим меркам означает „совсем недавно“), но в промышленности пока так и не был реализован никем, кроме нас. И знаете, я никогда не забуду отвисших до пола челюстей Лёши Шипилёва и Вовы Иванова! Паша знал, чем их удивить.

Команда JCK


И в полдвенадцатого ночи я подумал – ну всё, можно расслабиться и отдохнуть! Но меня на выходе из офиса Oraclе поймала команда JCK и предложила встретиться на следующий день.
Что мы и сделали. Я рассказал про наши текущие проблемы с JCK, ребята показали новые фишки в JCK. И вы знаете, я впервые в жизни ощутил себя клиентом Oracle на этой встрече! Ребята стараются для небольшой группы клиентов, таких как IBM, HP, SAP, и приятно было ощутить себя в этой компании.

Питер


В оставшееся до отлёта время мне удалось погулять по Питеру. Какой же это все-таки красивый город! Однозначно лучше каких-нибудь Сан-Франциско или Вашингтона.



В общем, поездка удалась, огромное спасибо организаторам!
Tags:
Hubs:
+44
Comments 43
Comments Comments 43

Articles

Information

Website
jugru.org
Registered
Founded
Employees
51–100 employees
Location
Россия
Representative
Алексей Федоров