Пэт Аллан: «Вы должны писать на языке, который делает вас счастливее»

Сегодня мы представляем вашему вниманию перевод интервью Пэта Аллана (Pat Allan), известного разработчика, приверженца Ruby, одного из победителей Ruby Hero Award. Что это за награда? Она присуждается победителями прошлого года тем участникам сообщества, которые в наибольшей степени проявили себя: создали значимый обучающий контент, разработали плагины и гемы, участвовали в проектах с открытым кодом.

Пэт Аллан — австралиец родом из Мельбурна, но, как он сам пишет в своем блоге, в последнее время практикует location independent lifestyle, а некоторое время назад даже сделал по этому поводу интересный доклад How to be a Ruby Journeyman, в котором рассказал, как фриланс-проекты и связи в Ruby-сообществах разных стран позволяют разработчику почувствовать себя с одной стороны свободным от географии, с другой — «своим» на разных материках.

Пэт приезжает в Киев на конференцию RubyC 5–6 ноября этого года, там можно будет послушать его доклад и пообщаться лично.

— Пет, судя по названию твоего блога, Freelancing Gods, фриланс — это часть твоей жизненной философии. Так ли это? Будучи фрилансером, минуя денежный вопрос, как тебе удаётся находить интересные проекты?

— Прежде всего, название моего блога никогда не было обо мне. Мне просто нравится идея богов, которые фрилансят друг для друга. Я определённо не вижу себя в качестве такого бога.

Тем не менее, мне и правда нравится определённая гибкость, которую я получаю от фриланса. Большую часть времени я могу работать над проектами, откуда только захочу, то есть, я почти не скучаю, тем более что на горизонте всегда новый проект.

На самом деле, я не очень-то занимаюсь поиском проектов — люди сами находят меня через друзей и знакомых. Это довольно завидное положение, и здесь, безусловно, не последнюю роль играет то, что программисты на Ruby очень востребованы в Австралии, да и вообще во всем мире.

— Как долго ты работаешь с одним заказчиком? Есть ли у тебя долгосрочные проекты?

— Значительная часть моей работы делается как раз для клиентов, с которыми складывается долгосрочное сотрудничество — от нескольких месяцев до года, а иногда и больше. Подавляющее большинство работы протекает вместе с командами разработчиков — с такими талантливыми людьми, как, например, Upstream, Envato и HyperTiny, — так что я не принимаю участие в активной поддержке проектов.

Получается всегда по-разному: с иными клиентами я могу работать от нескольких часов до нескольких дней. Тем не менее, в большинстве случаев я работаю над проектами от месяца и больше.

— Один из твоих последних постов был посвящён инструменту под названием Combustion. Как давно идея его создания пришла тебе в голову? Когда ты планируешь закончить реализацию?

— Какой-то период времени я работал над созданием Rails engine для клиента, а мне уж очень нравится писать тесты до начала непосредственной работы над кодом. До этого мне не приходилось писать Rails engine, поэтому я потратил некоторое время на изучение, как можно создавать для него тесты до кода — и тут выяснилось, что большинство разработчиков использовали целое приложение на рельсах, помещённое в директорию test.

Мне не понравился такой подход — в частности, он не соответствовал принципу DRY, — поэтому я поэкспериментировал на предмет того, какой минимум кода необходим для проведения всестороннего, полного интеграционного тестирования. Эксперимент вылился в combustion.

Как по мне, этот инструмент уже вполне готов к использованию — он справляется со своей задачей; я, как и некоторые другие, успешно им пользуюсь. Конечно, есть куда развиваться (например, поддержка Test::Unit), и я уверен, что со временем он эволюционирует.

— В одном из интервью ты сказал, что твоё главное резюме — это аккаунт на Github. Как заказчики находят тебя через него?

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

Для некоторых моих клиентов, которые далеки от разработки, я периодически обновляю свое «обычное» резюме или просто рассказываю им о проектах, к которым мне довелось приложить руку, и мы обсуждаем то, как я могу помочь им в работе над их проектами.

— Ты разработал несколько крайне интересных проектов на Ruby. Пожалуй, наиболее известным является thinking-sphinx. Не мог бы ты рассказать о нем побольше? Откуда возникла сама идея? Какие планы по его развитию в будущем?

— Около четырех лет назад в проекте на рельсах, над которым я работал, мне понадобился инструмент для поиска. Я решил использовать Sphinx, так что мне пришлось поиграться с несколькими существующими библиотеками, которые с ним работали.

Тем не менее, ни одна из них не делала того, что мне было нужно, поэтому я решил потратить выходные и написать кое-что свое — так и появился на свет thinking-sphinx. В начале он был не очень хорошим, но по мере того как я изучал Sphinx, мне удалось значительно его усовершенствовать. С тех пор и другие начали его использовать, вместе с чем появилось множество фич-реквестов и баг-репортов.

В будущем я надеюсь сделать его более лёгким и прозрачным, а также использовать некоторые новые функции Sphinx’а, включая индексы в реальном времени. За последние несколько месяцев я потратил некоторое количество времени, переписывая его, — но, скорее всего, в этом году релиз не увидит свет. Тем не менее я надеюсь, что, становясь ещё более умным, гем будет всё так же прост в использовании.

— Какова твоя роль в первоначальном проекте Sphinx? Существует ли какая-то общая стратегия развития Sphinx’а?

— Я не участвовал в разработке самого Sphinx’а — я не пишу на С++, поэтому не могу внести в него какие-либо изменения. Однажды я написал один патч, — касательно аутентификации, — но понятия не имею, примут ли его когда-нибудь или нет.

— Русским и украинским разработчикам было бы интересно узнать о том, что собой представляет инструмент babushka и откуда взялось такое название?

— На самом деле, разработчиком babushka является один мой друг, Бен Хоскинз. Данный инструмент — отличный способ автоматизации задач в духе TDD, где для каждой зависимости есть способ протестировать факт её выполнения. Она может быть использована где угодно: начиная от инсталляционных инструментов и заканчивая деплой-скриптами для серверов.

А назвал он её в честь матрешек (babushka doll — (англ.) матрешка), из-за того, что тут можно довольно прозрачно накладывать зависимости друг на дружку.

— Скажи, как создать успешный проект на гитхабе, которые сделает тебя популярным среди клиентов?

— Я считаю, что неотъемлемой частью создания популярного проекта является создание чего-то, что нужно именно тебе.

Если на самом деле тебе это не нужно, у тебя будет недостаточно мотивации работать над ним, а поддержка других людей при работе с ним превратится в рутину.

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

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

— Какой самый эффективный и быстрый способ стать известным программистом на Ruby — развивать свой проект или писать патчи к другим известным проектам?

— Скорее всего, написать свой собственный; но и патчи в другие проекты определенно не будут лишними. Вообще говоря, я не советую выбирать в качестве цели «известность» — гораздо лучше делать что-то хорошо, и помогать другим.

Зачастую это означает, что вы станете известным, — но это придёт лишь в качестве бонуса.

— В своем блоге ты пишешь: «В прошлых жизнях я работал с C#, ASP.NET, Visual Basic и Microsoft SQL Server. У вас не хватит денег заставить меня работать со всем этим ещё раз. Я серьёзно». Объяснишь? Что тебе нравится в Ruby, что делает тебя приверженцем этого языка и что такого плохого в перечисленных технологиях, что ты не станешь работать с ними ни за какие деньги?

— Многое сводится к тому, как просто разрабатывать на Ruby. Матс создал язык, чтобы сделать разработчиков счастливыми — и Ruby определённо делает счастливым меня. Я знаю, что это далеко не самый быстрый язык, но это с лихвой компенсируется его синтаксисом, простотой и сообществом. Чего стоят только библиотеки для тестирования.

Я вовсе не испытываю неприязнь к .NET или другим технологиям от Microsoft — всему найдётся свое применение, и если бы я разрабатывал под Windows, я бы писал только на C#. Тем не менее мне казалось, что ASP.NET сопротивляется тому, как работает веб (по крайней мере в те времена, когда я ещё на нем писал), а Rails позволили создавать вещи проще и быстрее.

В конце концов, вы должны писать на языке, который делает вас счастливее, будь то Ruby, C#, PHP, Python, Cobol... да что угодно.

— Пэт, кроме разработки ты занимаешься организацией интересных событий — Trampoline и Rails Camp. Насколько я понял, оба организовываются силами участников. Скажи, исходя из собственного опыта, в чем ключ к успеху мероприятий подобного рода, когда у тебя заранее нет подготовленной программы?

— Мне кажется, что очень важно иметь некую структуру, даже если её практически не видно. Дайте понять всем участникам, как на раннем этапе, так и во время запуска, что у них самих есть контроль над тем, как пройдёт мероприятие, и, следовательно, они сами ответственны за то, как много удовольствия получат.

В случае с Rails Camp, всем людям нужно сообщить, что каждый может организовать обсуждение, покодить на своих проектах или поработать с другими, либо же просто пообщаться. Мы помогаем людям организовывать собрания, предоставляя место и время, но всё остальное происходит очень гибко.

Trampoline чуть более структурирован — у нас очень чёткие временные рамки для собраний, но, опять-таки, мы делаем упор на то, что каждый должен принять участие, а не просто посидеть — в этом-то и суть. Кроме того, у нас очень чётка цель: поделиться тем, что сам считаешь достойным внимания. Сохранять такой контекст крайне важно.

Итак: определись со структурой — как будут проходить собрания? Кто присматривает за едой? Что должны сделать люди, чтобы получить билет? Ответы могут быть любыми, но будьте уверены, что вы сами, как и потенциальные посетители, их знаете.

Интервью подготовлено и проведено оргкомитетом конференции RubyC.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU