Pragmatic Perl

Выпуск 26. Апрель 2015

Интервью с Виктором Турским

Виктор Турский (koorchik) — украинский Perl-программист, сооснователь компании WebbyLab

Как и когда научился программировать?

Это длинная история. В целом, я никогда не собирался быть программистом, даже когда уже работал им, я все еще не собирался им быть. Так вот, в детстве мне родители купили книгу «А я был в компьютерном городе» (поищи в google, там классные картинки). Это было то ли ли в 3-м, то ли в 4-м классе, и думаю, что после этого я загорелся компьютерами. Правда первый компьютер у меня появился только через 4 года (это был старый «commodore 64»), но к тому моменту я прочитал о них все, что мог найти. В 9-м классе мне достался другой очень «крутой» компьютер: 1MB Ram, CPU 8086(4 Mhz), 5.25 floppy drive. Вот тогда я и начал играться с Basiс, разобрался с DOS, с драйверами, файловой системой и так далее. Помню, что первое, что я написал, была программа, которая решала квадратные уравнения. А делать что-то более полезное я стал значительно позже — в универе, писал разного рода приложения на Bash, AWK, Perl, Visual Basic.

Какой редактор используешь?

В свое время, много лет сидел на Eclipse + Epic, но года три назад полностью перешел на Sublime Text. Vim тоже пробовал, через 2-3 месяца понял, что я менее эффективен в нем. Сейчас у нас в офисе не услышишь холиваров по поводу редактора — Sublime Text всех подружил :)

Как и когда познакомился с Perl?

Как я уже сказал, я никогда не планировал быть программистом. Меня больше интересовали информационная безопасность, сети, взломы, архитектура операционной системы. Учась в университете, я часто игрался с разными эксплоитами, бекдорами, сетевыми утилитами и т.д. Чаще всего они были написаны на C++ и реже на Perl. Я понимал, что умение программировать мне сильно поможет в моем увлечении. Эксплоиты бывало содержали какую-то мелкую ошибку, и нужно было ее исправить (такой себе механизм защиты от script kiddies). Исправить ошибку мне хватало скилов, но написать какое-то сетевое приложение я не мог. Тогда я купил две книги «Сетевое прораммирование на Perl» и книгу с верблюдом. Кроме того, что Perl позволял легко писать сетевые приложения, он отлично справлялся с задачами вычистки лишних данных из логов и т.д. Если говорить о чем-то полезном, то одним из первых моих скриптов был скрипт, который читал excel-файл, смотрел, кто не заплатил абонплату за сеть в общаге, а потом ходил по телнету на управляемый свитч и блокировал неплательщиков по мак-адресу :).

С какими другими языками интересно работать?

Сейчас много работаю с JavaScript. Поначалу, после Perl, меня от него коробило, но когда появились ES5 и ES6, то отпустило. Сейчас же стартую все проекты именно на JavaScript.

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

Слежу за Perl6. Не думаю, что когда-то у меня будет продакшен проект на нем, но сам язык просто кладезь интересных подходов и решений. Чего стоит только банальный блок CATCH, давно мечтал о таком. Или «reduction operators». Высокоуровневые примитивы для работы с многопоточностью, как то: каналы, промисы и т.д.

Считаю, что со многими языками интересно работать (если это не VB.Net). По факту же интерес вызывает не просто сам язык, а задача, которую ты на нем решаешь.

Что, по-твоему, является самым большим преимуществом Perl?

Мне нравится гибкость Perl и его стабильность. Стабильность интерпретатора и всей экосистемы. Также у Perl есть своя философия, если ты ее понимаешь, то Perl никогда не стоит у тебя на пути, он ведет себя ожидаемо.

Есть еще масса позитивных мелочей. Например, в Perl действительно круто реализована нестрогая типизация. Благодаря мономорфным операторам (и use warnings) я никогда не задумываюсь, число или строка в переменной. В том же JavaScript это сделано очень криво. Вроде бы там нестрогая типизация, но ввиду полиморфности операторов я всегда должен помнить типы, иначе два плюс два даст двадцать два. Нигде мне не было так удобно использовать регулярные выражения, как в Perl. Когда я выкладываю модуль на CPAN, он будет протестирован просто в безумной массе окружений. Не встречал нигде такого крутого CI. Качество модулей на CPAN значительно выше, чем на том же npmjs, и меньше ломаешь голову, что же из этого хлама заработает.

В общем, вывод следующий: делать работу на Perl — это «Fun». Думаю это и есть самое большое преимущество.

Что, по-твоему, является самой важной особенностью языков будущего?

Никогда не задумывался об этом. Естественно, можно сказать, что это многопоточность и без нее правда никуда, но давай поразмыслим. Язык программирования — это лишь инструмент для решения задач. То есть, язык будущего — это тот язык, который сможет решать задачи и проблемы будущего.

Полагаю, что в будущем будут усиливаться две проблемы:

1. Дефицит программистов на рынке и их высокая стоимость.
2. Рост количества данных.

Более детально разберем проблему №1. Нужно откуда-то брать программистов. Единственный способ — это обучение. Но крутыми программисты становятся после многих лет работы. Для того, чтобы удовлетворить спрос на программистов, нам нужно уменьшить срок их подготовки, чтобы они могли решать задачу сложности X не через 2 года, а через 5 месяцев, например. Мы помним, что сложность решения задачи состоит из «essential complexity» и «accidental complexity». Брукс говорил, что проблемы «accidental complexity» в значительной мере решены и потенциал для уменьшения «accidental complexity» минимален. В целом это верно, особенно, если мы разрабатываем, например, бухгалтерскую систему, где очень высокий уровень «essential complexity». Но сегодня масса приложений значительно проще и уменьшение «accidental complexity» сильно бы сократило время разработки и повысило стабильность продукта.

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

1. Язык не должен заставлять пользователя изучать много концепций и создавать сложности. То есть Java это не язык будущего :)
2. Сообщение об ошибках. Язык будущего должен обладать мощным статическим анализатором и предупреждать об ошибках заранее. И самое главное, все ошибки должны быть понятными!
3. Упрощение отладки кода. Это не только про инструменты, но и про сам синтаксис языка. Синтаксис должен быть лаконичным и однозначным.
4. Разделяемое изменяемое состояние часто бывает источником проблем (как говорится, «Shared mutable state is the root of all evil»). Должна быть возможность легко сделать структуры неизменяемыми. Например, я хочу заморозить иерархическую структуру, я говорю freeze(struct). В JavaScript есть похожее Object.freeze, но там имеется два недостатка: нет возможности создать новую структуру на базе существующей, при попытке изменения не возникает ошибка.
5. Паралельная обработка данных (многопоточность, асинхронность и т.д). Все это, само по себе, является сплошным accidental complexity. Одно из тех мест, где еще остался высокий уровень сложности. Язык будущего должен иметь встроенные (как регулярки в Perl) высокоуровневые абстракции (Promises, Channels, Generators…), которые инкапсулируют эти сложности.
6. Организация связей между сущностями. Это одна из ключевых проблем. ООП решает эту проблему лишь частично, а часто даже создает лишние проблемы. Раньше мы говорили про наследование, сейчас говорим про композицию. Стали модными декораторы, роли (traits) и так далее. Кто-то скажет, что функциональное программирование эти проблемы решает. Не буду спорить, но мое видение такое — универсального решения еще нет и возможно не будет. Мы не знаем, что наиболее эффективно в конкретном случае. Тут лучше отталкиваться от обратного — язык будущего не должен включать (по умолчанию) ничего, что сильно повышает риск создания спагетти-кода.
7. Развертывание приложения и управление зависимостями.
8. И самое главное. Должен быть «Fun». «Fun» мотивирует и ускоряет процесс обучения.

Ух, жесть. Если не знаешь ответа, то коротко ответить не получится :).

Что думаешь о будущем Perl?

Если говорить про Web-разработку, то в ближайшие 5 лет JavaScript будет набирать все большую популярность. Perl, Ruby, Python будут терять позиции. Perl, как и раньше, будет отлично справляться со своими задачами, но он будет сидеть в своей нише. Например, даже Ruby — язык, который сейчас ассоциируется с веб-разработкой, вытесняется nodejs. Не думаю, что и Perl сможет увеличить свою долю на этом рынке. Если говорить про использование в общем, то в ближайшие 10 лет ничего не изменится.

Хотелось бы, чтобы выстрелил Perl6, но для этого нужен большой продакшен на нем и продвижение.

Что такое LIVR?

Каждый программист неоднократно сталкивался с необходимостью проверки пользовательского ввода. Занимаясь веб-разработкой уже более 10 лет, я перепробовал массу библиотек, но так и не нашел той единственной, которая решала бы поставленные мною задачи. Три года назад было решено написать собственный валидатор, который был бы идеальным. Так появился LIVR (Language Independent Validation Rules, http://livr-spec.org). Есть реализации на Perl, PHP, JavaScript. Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает как на бекенде, так и на фронтенде. Также есть сторонняя реализация, написанная на python, мы на python не пишем — фидбек дать не могу. Поиграться с валидатаром можно тут: webbylab.github.io/livr-playground.

В Pragmatic Perl уже была статья про LIVR, можно с нее начать. Сейчас пишу более детальную статью, будет доступна на хабре.

В твоей компании часто используется Mojolicious. С чем это связано?

Mojolicious мне очень нравится концепцией. Нет, я не про то, что у него нет внешних зависимостей. Мне нравится, что это Web-фреймворк, который делает акцент на Web. Он не пытается решить проблемы хранения данных и прочее, а концентрируется на Web-составляющей: websockets, HTTP/2, HTML Parsing. То есть, делает то, что должен делать Web-фреймворк, но не скатывается до уровня микро-фреймворков. Такой подход — редкость, обычно либо микрофреймворк, либо убийственно толстый fullstack-фреймворк. Mojolicious — это идеальный компромисс.

Требуется ли бизнесу Perl? Как нанимаете Perl-программистов?

Perl отличный язык, но я считаю, что в веб-разработке будущее за JavaScript. Пересекающийся стек технологий и на фронтенде, и на бекенде — это значительно эффективнее.

У нас наиболее крупные проекты на Perl, но в новых проектах Perl используется только тогда, когда JavaScript не справляется (есть такие моменты :)). Каких-то особенностей в найме Perl-программистов нет, возможно только то, что мы выросли из Perl-комьюнити и там больше знакомых.

Используете ли какую-то методологию разработки, как контролируете и улучшаете качество своих продуктов?

Подходы варьируются от проекта к проекту и от заказчика к заказчику, но это всегда Agile (часто SCRUM, но не во всех проектах). Обычно мы просим заказчика выделить одного человека, который будет ответственен за постановку требований и за прием результата. Мы же, со своей стороны, тоже предоставляем человека, который будет точкой коммуникации для заказчика. Практически всегда работаем без предоплаты, чтобы минимизировать риски заказчика. Если не сделаем то, что хочет заказчик, то оплату не получим — все очень просто. Это очень мотивирует строить эффективный процесс в компании. В целом ничего нового, просто стараемся использовать лучшие практики и наиболее эффективные инструменты.

С технической стороны ничего особенного:

• Используем Git, каждая задача делается в отдельной ветке.
• Test coverage для бекенда должен быть не менее 80%.
• Все задачи проходят code review (используем gitlab для этого).
• Перед тем, как тикет попадет в master, должны успешно пройти тесты. Для continuous integration используем Gitlab-CI.
• Каждая задача проходит проверку тестировщиком. Он ответственен за то, чтобы до заказчика доходил только качественный продукт.
• Всегда пишется документация к REST API.
• Разворачиваем все через Ansible.
• Проекты ведем в Redmine.

Если интересен стек технологий, то вот он http://stackshare.io/webbylab/webbylab.

Можно ли совмещать управление с разработкой?

Сейчас я практически перестал писать код по проектам клиентов (только изредка берусь за какие-то уж очень критические куски). Но код писать важно, иначе перестанешь чувствовать разработку и ее проблемы. В связи с этим, я пишу код для проектов, где нет жесткого дедлайна. Это обычно внутренние инструменты, библиотеки, какие-то proof of concepts и т.д.

Я всегда стараюсь пропустить через себя технологию перед тем, как начинать ее использовать на уровне компании. В связи с этим я могу взять уже готовый проект и попробовать его переписать на другой технологии и сравнить, будет ли это эффективней.

Сколько времени проводишь за написанием Perl-кода?

Сейчас пишу мало кода в принципе. На Perl пишу еще меньше — обновляю внутренние инструменты, модули на CPAN.

Вы спонсировали несколько Perl-мероприятий. Чем руководствовались при принятии этого решения? Будете ли продолжать?

Основатели компании вышли из Perl-комьюнити. Спонсорство, предоставление офиса компании на технические встречи, участие в Perl-хакатонах — это все возможность держать связь с комьюнити. Мы время от времени спонсируем интересные для нас мероприятия. Например, второй год подряд мы являемся спонсорами iForum. Это конференция связана с решением основать компанию, мы ее любим сильно и всех приглашаем посетить.

Стоит ли советовать молодым программистам учить сейчас Perl?

Молодым программистам советую идти работать. Если работа подразумевает использование Perl — отлично, и это будет замечательный опыт, если нет — ничего страшного. Только код, доведенный до продакшена, делает из тебя программиста, другого пути нет :).

Вопросы от читателей

Когда будут еще статьи для журнала?

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

Какую следующую конференцию планируешь посетить?

Планирую быть на iForum-2015 вместе со всей командой. Как и уже упоминал, мы опять спонсоры этого мероприятия. У нас есть традиция: каждый год компания оплачивает всем сотрудникам поход на iForum, и мы там делаем коллективное фото в футболках WebbyLab. Эти фото потом висят по офису, всегда приятно смотреть, как всего за чуть больше трех лет мы выросли с четырех до 20 человек.

Что значит koorchik?

Сколько раз мне уже этот вопрос задавали :). koorchik я уже около 20-ти лет, еще со школы повелось. То есть я стал koorchik-ом еще до того, как появились соцсети и у меня интернет. Просто среди друзей кто-то меня так назвал и прицепилось.

■ Вячеслав Тихановский