В этом году RubyConf был вдохновляющим, увлеченным и веселым опытом. Если вам не повезло лично присутствовать, я очень рекомендую взглянуть на http://rubyconf13.multifaceted.io , мультимедийный сайт о RubyConf, созданный Ninefold , хостинговой компанией Sydney Rails. Они собрали потрясающий набор интервью, слайдов, резюме выступлений и твитов с конференции. И только на этой неделе Confreaks начал публиковать видео сессий в Интернете ; Есть много сеансов, которые я пропустил лично, которых я не могу дождаться, чтобы увидеть.
Сегодня, однако, я хотел бы поделиться несколькими неожиданными техническими знаниями, которые я узнал во время конференции, что меня удивило . Помимо всех замечательных людей, с которыми я встречался во время разговоров в коридоре, за ужином и обедом, удивительные кусочки знаний — то, что выделяется в моей памяти, когда я пишу это через три недели после окончания конференции.
 |
| Коичи Сасада говорит о Управление объектами на Ruby 2.1 |
Эмпирические данные, подтверждающие слабую гипотезу поколений
Если вы когда-либо изучали теорию информатики, стоящую за сборкой мусора, вы, вероятно, слышали о гипотезе слабого поколения . Предполагается, что большинство объектов умирают молодыми, и ваше приложение будет использовать большинство созданных им объектов только в течение относительно короткого времени. Например, предположим, что я создаю новый объект Ruby:
obj = Object.newСкорее всего, я буду использовать этот объект только в рамках одного метода или в качестве промежуточного значения в некоторых расчетах. Как только этот метод возвращается, объект извлекается из стека и его память может быть возвращена в систему. И наоборот, мой код будет использовать только несколько объектов в течение более длительного периода времени. Эти объекты чаще живут дольше.
Эта гипотеза позволяет разработчикам языка создавать системы сбора мусора, которые по-разному обрабатывают новые и старые объекты. Например, JVM (используемая JRuby наряду со многими другими языками) управляет памятью для молодых объектов совсем иначе, чем для старых или зрелых объектов. Это известно как сборка мусора поколений . Рубиниус также использует эту идею.
Компьютерные ученые называют это гипотезой, поскольку нет простого способа доказать, что это правда. Мы должны полагаться на эмпирические данные. Конечно, разработчики могут создавать и использовать объекты для любых целей. Гипотеза просто описывает, как разработчики обычно используют объекты в большинстве приложений.
В своем превосходном выступлении на RubyConf « Управление объектами в Ruby 2.1» Коичи Сасада ( @ _ko1 ) описал, как в следующем выпуске MRI Ruby версии 2.1 теперь также будет содержаться алгоритм сбора мусора поколений. Но больше всего меня поразило то, что меня удивило , так это слайд:
От: http://www.atdot.net/~ko1/activities/rubyconf2013-ko1_pub.pdf
Здесь вы можете увидеть, что Коичи на самом деле предоставляет эмпирические доказательства слабой гипотезы поколений. Здесь он измеряет время жизни различных объектов Ruby, созданных при запуске утилиты RDoc . Обратите внимание, что большинство объектов, созданных RDoc, умирают очень быстро, после одной или двух сборок мусора. Это всплеск в левой части графика. Между тем, на правой стороне графика, скромное количество объектов выживает гораздо дольше; используя легенду внизу, вы можете увидеть, что это часто классы, модули и включенные классы (внутренние копии модулей).
Самое интересное и удивительное в этом графике то, что в центре очень мало объектов. После первоначального всплеска слева объекты почти не отображаются, пока вы не достигнете примерно 70 прогонов ГХ, где происходит небольшой всплеск, а затем примерно при 100 прогонах ГХ, где был измерен больший набор зрелых объектов.
Я нашел этот эксперимент, чтобы быть захватывающим! Одно дело читать о слабой гипотезе поколений в учебниках CS; это совсем другое, чтобы увидеть реальные данные. Глядя на этот график, легко понять, почему Koichi и основная команда Ruby так усердно работают над добавлением GC поколений в Ruby 2.1: как только объект становится зрелым, как только он проходит после первой или второй сборки мусора, не нужно беспокоиться об этом еще раз. Согласно графику зрелые объекты, скорее всего, будут жить очень долго. В Ruby 2.1 код сбора меток и мусора будет сосредоточен только на молодых объектах, которые появляются в левой части диаграммы.
 |
| Нелл Шамрелл во время ее отличного RubyConf Презентация: Под поверхностью: Использование истинная сила регулярных выражений в Ruby |
Как смотреть в Regex
Я был удивлен снова всего через пару часов после презентации Коичи. В той же комнате Нелл Шамрелл ( @nellshamrell ) выступила с потрясающим спектаклем, рассказав счастливой аудитории о регулярных выражениях в Ruby. Театральная подготовка Нелл просвечивала; она была очень уверена, выступая публично, и было ясно, что она репетировала представление так же, как актриса Шекспира готовилась к роли в Ромео и Джульетте. Она не только объяснила, как использовать регулярные выражения в Ruby, но даже углубилась в то, как они реализованы внутри Ruby.
Я думал, что много знаю о регулярных выражениях, но Нелл доказала, что я неправ. Она объяснила и использовала одну деталь синтаксиса регулярных выражений, о которой я никогда раньше не слышал, известную как « смотреть за спиной» Вот слайд из презентации Нелл, где она использует эту неясную, но мощную функцию.
От: http://www.slideshare.net/NellShamrell/beneath-the-surface-rubyconf-2013
Это часть более длинного примера, который Нелл рассказала нам о том, как преобразовать случай со змеей в случай с верблюдом (первоначально вдохновленный твитом от Авди ). Я не буду повторять все детали здесь, кроме как чтобы указать на запутанный и незнакомый синтаксис в середине выражения регулярного выражения:
(?<=_)[a-z]
Часть [a-z] Это означает: сопоставить любой символ от a до z или, другими словами, любую строчную букву. Но как насчет (?<=_) Оказывается, это пункт «оглянуться назад». Это означает, что нужно искать текущее потенциальное совпадение и возвращать его как фактическое совпадение, только если предыдущий текст удовлетворяет данному предложению регулярного выражения . ?<=(?<=_)_ ».
Например, это регулярное выражение соответствует первой строчной букве в целевой строке t :
str = "this is a long string"
puts /[a-z]/.match(str)
=> t
Но это второе регулярное выражение соответствует только одной строчной букве, которая следует за подчеркиванием, l :
str2 = "this is a _long string"
puts /(?<=_)[a-z]/.match(str2)
=> l
Оказывается, есть также модель «смотреть вперед». Чтобы узнать больше об этих мощных инструментах регулярных выражений, посмотрите презентацию Нелл или посмотрите этот учебник: http://www.rexegg.com/regex-lookarounds.html
 |
| Марк Бейтс носит халат отеля во время его презентация Mangling Ruby с помощью TracePoint |
Сколько вызовов методов для отображения страницы с использованием Rails?
Последний сюрприз, о котором я расскажу сегодня, был обнаружен Марком Бейтсом во время его работы с функцией TracePoint . Как описал Марк, новый API TracePoint позволяет вашему Ruby-коду уведомлять интерпретатор при каждом событии определенного типа: вызове метода, выполнении строки кода, определении класса или модуля и т. Д.
Марк показал аудитории, как использовать TracePoint, на нескольких интересных примерах, в том числе о том, как создавать абстрактные классы и интерфейсы, как если бы вы использовали Java. Своим обычным интересным занятием Марк познакомил нас с внутренностями Ruby с помощью API-интерфейса TracePoint.
Но один эксперимент, проведенный Марком с использованием TracePoint, удивил меня! Он создал простое веб-приложение Rails «hello world», содержащее один контроллер, маршрут и представление, а затем измерил, сколько вызовов методов было выполнено инфраструктурой Rails при создании страницы. Как объяснил Марк, это было довольно просто сделать с помощью TracePoint, поскольку вы можете вызывать Ruby каждый раз, когда происходит вызов метода.
Конечно, Марк попросил аудиторию угадать, сколько вызовов методов, по нашему мнению, потребуется Rails, чтобы показать страницу. Люди догадались 10000, 20000 или даже 50000. Но никто не ожидал фактического ответа:
Я обнаружил, что это поразительно! Как это возможно, так много вызовов методов требуется? Rails — сложная структура, но для чего могут использоваться все эти вызовы методов? Интересно, что на самом деле представляют собой эти методы и как бы меньшие фреймворки, такие как Sinatra или даже Rack, сравнивались с Rails.
И многое другое!
Эти три сюрприза — лишь небольшая часть знаний и разговоров, которыми поделились на RubyConf. Это была одна из самых веселых и интересных конференций, которые я когда-либо посещал. Вот еще несколько фотографий с моей собственной камеры… обязательно ознакомьтесь с видео Confreak , а также с контентом на http://rubyconf13.multifaceted.io .
Увидимся в следующем году в Сан-Диего на RubyConf 2014!
 |
| 12-летняя Кэти Хагерти не только дала основной доклад, она сохранила Зрители в восторге за 45 минут! |
 |
| В какой должна быть самая потрясающая демка Я когда-либо видел, Рон Эванс использовал Руби управляйте летающими роботами, все запечатлено на видео! |
 |
| Мац смотрит захватывающую презентацию на BioRuby моими друзьями Доэль Сенгупта и Ману Сингхал. |
 |
| Что касается меня, это было захватывающе дать подписанную копию моей книги Мацу. |