Шавье Нориа (в оригинале — Xavier Noria) — человек далеко не безызвестный в сообществе Ruby. Будучи разработчиком из Барселоны, он сумел стать членом команды ядра Ruby on Rails. Кстати, Шавье также выиграл награду Ruby Hero на RailsConf 2010. Возможно кому-то из вас, уважаемые читатели, удалось с ним встретиться: он появлялся в этом году на нескольких конференциях разработчиков в Европе.
Пожалуй, наибольшее впечатление на меня произвела такая черта Шавье как «Садовник кода» (в оригинале — «Code Gardener»). Эту фразу он оставил в одном из небольших коммитов, сделанный им более двух лет назад.
Недавно мне удалось побеседовать с Шавье на различные темы: его биографии, новинках в Rails 4, его страсти к документации и, пожалуй самое главное, о философии значимости маленьких изменений.
Начало
Как начался твой путь Ruby on Rails?
Двенадцать лет назад я круто изменил вектор своей карьеры и стал работать программистом. Мне тогда было уже 30 лет и решение это было весьма серьезным, но решиться на этот шаг помогла моя любовь писать код.
Я стал работать в исследовательской лаборатории, где в то время писал на Java и на Perl. На протяжении 7 лет также читал лекции по языку Perl в Университете Барселоны. В 2005 году кто-то поинтересовался у меня: нет появилось ли чего-то нового, что зацепило бы мое внимание? А в то время почти каждый только и норовил, что обсудить Ruby on Rails. На мой первый (и поверхностный) взгляд он этого и вправду заслуживал. Вот я подумал, что RoR выглядит и вправду многообещающе. Тогда у меня не было большого опыта работы с Ruby, я просто немного с ним «поигрался», поскольку питаю теплые чувства к динамическим языкам.
Итак, когда мы с коллегами попробовали Rails уже на реальном проекте то пришли в восторг. Далее уже был написан полноценный интернет-магазин на одних рельсах. Позже мы также основали свою компанию в Испании, занимающуюся веб-проектами. RoR стал нашим брендом.
Кого ты имеешь ввиду под словом «мы»?
В первую очередь я говорю о Agustín Cuenca, с которым начался совместный проект в 2005 году. Вместе с ним была создана компания ASPgems в 2006 году совместно с другими нашими партнерами.
Работа над ядром Rails
Расскажи о том, как ты стал частью команды разработчиков Rails. Как начался твой путь?
Я участвовал в жизни свободного программного обеспечения на протяжении 10 лет: работал над некоторыми модулями Perl, помогал как мог в IRC и прочее. Что касается самих Рельс то, найдя баг или еще что-то, что можно было бы пофиксить, я всегда старался прислать патч для исправления найденной проблемы. Но не участвовал в решении тикетов. Когда мне что-то было нужно, я просто писал код и отправлял патч.
А все началось с моего желания заняться документацией Rails. Я вообще считаю, что с этим в сообществе Ruby наблюдаются определенные проблемы, но это дает также отличные возможности для внесения своего вклада. Так вот, в Рельсах уровень документации в то время меня совершенно не удовлетворил. И вот, у Pratik Naik возникла отличная идея создать проект под названием «docrails» — это одна из веток Rails для быстрых изменений и исправлений в документации, которая регулярно сливается с мастером (основной веткой) проекта. В самом начале для доступа приходилось связываться с ним, но сегодня такой проблемы больше нет: у проекта появился публичный доступ.
Я начал работать над docrails как сумасшедший. У документации было сразу несколько направлений для развития: одно из них — это описание самого контента и функций, что, как вы понимаете, очень важно для проекта. Конечно, были и другие направления, требующих исправлений, такие как согласованность документации: не было никаких гайдлайнов или правил, а была сплошная каша. Вот где и пригодился мой опыт корректора — я занимался вычиткой книг по математике в течение нескольких лет до того, как ушел в программирование.
Ничего себе!
Да! У меня наметанный глаз. Если что-то должно было быть выделено курсивом и при этом не было, то от меня это не уходило незамеченным!
Итак, мы установили некоторые правила для документации и я принялся активно внедрять эти изменения в проект RoR. Была проделана внушительная работа, которую, в целом, многим совершенно не видно, но мне было плевать, я просто исправлял, то, что хотел починить. После этого каким-то образом началась работа над кодом. Соотношение было примерно 80/20 с перевесом в сторону документации, разумеется. В конце-концов, ребята из команды разработчиков Rails узнали о моих вкладах и мы начали плотнее общаться друг с другом, таким образом я стал узнавать проект глубже. После некоторого времени меня пригласили в команду.
Поздравлю! Это восхитительно! Расскажи, какого этого — работать в команде ядра Rails? Это весело? Сложно? Изматывающе?
Работать здесь — это очень круто! В команде смогли найти баланс между работой поодиночке и работой в группе. Для важных вещей мы проводим обсуждения и стараемся придти к единой точке зрения. Но в большинстве случаев мы работаем одни, каждый над теми участками, которые ему наиболее интересны. Для общения используется комната в Campfire и проект в Basecamp.
А общаетесь ли вы друг с другом голосом? Хотя бы в скайпе, ну или вживую?
В моем случае все пишется либо в Campfire, либо в Basecamp. Очень редко когда используется электронная почта. Насколько мне известно, José и Yehuda в настоящее время работают в паре, удаленно. Обычно для общения хватает текста.
Rails 4
Многие люди интересуются, что же нового нам готовит Rails 4? Знаю, что времени немного, но можешь ли ты приоткрыть завесу?
Это большой релиз с кучей новых фич. В последние дни я просматривал change log, готовя материал для заметок о выпуске новых Рельс. Первое, для использования Rails 4 необходима версия Ruby 1.9.3.
… И это связано с тем, что вы используете код, работающий только в 1.9.3?
Среди разработчиков было несколько дискуссий, по итогам которых было принято решение о фокусировке на последнем стабильном релизе Руби, дабы не тратить время на предыдущие версии. Официальная поддержка будет только для 1.9.3. Кто-то, возможно, и сможет запустить Rails 4 приложение на 1.9.2, но здесь он будет один на один с его программой и возможными проблемами. Абсолютно точно мы не будем поддерживать Ruby 1.8, поскольку много кода было переписано с поддержкой только 1.9.
Что ж, с этим ясно. Ваши тесты крутятся только под 1.9.3?
Да. Среди новых фич мне нравится то, что мы теперь используем метод PATCH в качестве first class citizen.
И что же метод делает? Обновление?
Да, идея заключается как раз в обновлении им данных. Ранее это происходило с помощью метода PUT, но, вообще говоря этот метод должен создавать или обновлять целую сущность. В то же время, как правило, полный ресурс не отправляется. И поэтому, теперь в формах, используемых для обновления ресурса, в скрытом параметре «_method» будет использоваться PATCH.
Для чего разработчикам знать об этом? Для плавного перехода?
Конечно, именно для плавного перехода!
Есть еще кое-что, что многие люди хотели бы изменить. Это контроль массового назначения атрибутов. Раньше необходимые методы располагались исключительно в моделях и многим это не нравилось, они хотели бы, чтобы этот механизм был доступен в контролерах. Итак, это свершилось! В Rails 4 это фича называется strong parameters. Отныне этот механизм доступен в контролерах, можете попрощаться с «attr_accesible» и «attr_protected». Но если возникнет такое желание, то старую функциональность можно вернуть с помощью плагина.
Еще одна приятная возможность — это API для очередей. Вы можете подхватить несколько очередей и использовать одно общее API для работы с ними. Благодаря этому новшеству теперь даже можно, к примеру, асинхронно отправлять письма!
Очень любопытно!
К слову, еще одна очень важная фича, которую мы создали, называется «Russian Doll caching».
Можно ли вкратце рассказать об этом?
Допустим, вы хотите кэшировать все партиалы в какой-либо вьюхе, но у вас есть двойной или тройной уровень вложенности. В таком случае необходимо использовать какой-то временной штамп, для того, чтобы ключи автоматически исчезали через некоторое время, ну, и так далее. Если же вы меняете что-то из статичного контента в одной из вложенных вьюх/партиалов, то родительский контейнер начинает содержать неверные данные из-за кэширования.
До того, как появилась наша фича нужно было самому вручную разбираться с такими проблемами. Теперь все это Rails 4 решает за вас, автоматически генерируя MD5 ключи для подписи представлений с данными.
Еще одно важное замечание. Мы убираем Active Resource из Rails, поскольку он мало где используется. Его можно будет установить с помощью плагина. Конечно же, это не все грядущие изменения.
Садовник кода
Помнишь ли ты мою прошлогоднюю статью, в которой я описал тебя как «Садовник кода»?
Очень необычно, что кто-то обращает внимание на небольшие изменения кода. Подобное сравнение очень приятно!
Ты и вправду тратишь много времени на подобные небольшие правки, облагораживая код?
Конечно. Если что-то привлекло мое внимание и требует исправления, то я беру и исправляю. Мне одинаково нравится и написание больших проектов, и унификация кода, и исправление небольших ошибок.
Как вижу, тебе нравятся копаться в деталях.
Я думаю, что подобные небольшие вложения в проект очень нужны, потому что именно они придают коду законченную форму и наводят красоту.
У меня нет различий между тикетами — и исправление небольшой ошибки и фикс бага важны также как любое другое изменение в коде. Если кто-то пришлет мне подобные поправки, они будут приняты тотчас же, если это, конечно, не монструозные патчи. По этой причине мне так нравятся docrails — они продвинули подобные идеи.
Среди людей, которые читают эту статью, скорее всего есть те, кто хотел бы внести свой вклад в Rails, но не знает как. Что бы ты им мог посоветовать?
Открывайте Github и начните работать над тикетами. Подобная работа включает в себя множество возможностей: создание патча для исправления проблемы, тестирование того, что патч все еще работает в новых версиях и прочее. Если же вам по душе работа с документацией, то вы можете поискать проекты с небогатой документацией (которых в сети много) и помочь в ее доработке. Проект Rails Guides всегда рад подобной помощи (в русском сегменте это rusrails.ru). Это очень-очень важная часть для любого проекта!
Ruby конференции
Ты посетил множество различных конференций за последние месяцы: RailsClub Moscow, BaRuCo, RuLu 2012, RailsBerry, EuRuKo. Есть ли в них что-то, что больше всего тебе понравилось?
Пожалуй, так как в этом году я раньше не путешествовал. На каждой из них (за исключением EuRuKo) я выступал. Веселым вышел год. Но я езжу на конференции ради встреч с людьми. Мне конечно нравится выступать, но это явно не мой основной стимул.
Так ты любишь посидеть в баре? Или тебе больше нравится после-барное времяпровождение?
Я люблю перерывы. Признаюсь честно: не любитель тусовать, в час ночи я предпочитаю отправиться в отель.
Так рано? А я-то думал, что в Испании вы в это время только обедаете!
Ха, это правда. Вообще, на второй день конференции я люблю расслабиться. Конференции, как правило, бывают двух видов: первые, наполненные выступлениями и вторые (более редкие) с периодическими перерывами по полчаса и более. Я предпочитаю второе, поскольку в этом случае удается общаться с людьми и меньше просиживать штаны.
Собираешься ли ты когда-нибудь приехать на какую-либо конференцию в США?
Давай будем честны — это слишком далеко от места, где я живу. В США меня занесло лишь однажды и то, только потому, что организаторы «предложили» поучав… То есть, потому что мне должны были вручить награду Ruby Hero. А случилось это в 2010 году в Балтиморе.
Данное интервью является переводом: этой статьи
Обо всех ошибках просьба сообщать в личку.
Автор: Loremaster
