Юрий Сидоров о transmission-remote-gui, паскале и стереотипах

Помните серию переводов интервью из GNOME Journal? Иногда они возвращаются :-) То есть я решил продолжить публиковать беседы с разработчиками свободного ПО. Правда, на сей раз переводить ничего не требуется, буду общаться с русскоязычными деятелями open source.
В каждой советской семье вслед за холодильником и телевизором появляется маленькая коробочка, устройство, называемое в народе «торрентокачалкой». Если на устройстве работает Transmission, вам волей-неволей придётся как-то им управлять, а выбор невелик на самом деле. Давно и с удовольствием в качестве «рулевого» использую transmission-remote-gui. Автор этой программы, Юрий Сидоров, согласился ответить на пару каверзных вопросов.

Расскажите, пожалуйста, пару слов о проекте, как он начинался. Это одна из тех идей, которые воплощаются для собственных нужд или по каким-то иным соображениям?
Началось всё с того, что в конце 2008 года я приобрёл медиаплеер, где в качестве торрент-клиента был Transmission 1.40. Для управления им использовался достаточно бедный по функционалу веб-интерфейс. Потом я наткнулся на удалённого клиента для Transmission, написанного под платформу .NET. В то время он произвёл на меня грустное впечатление как по функционалу, так и по внешнему виду. Но, благодаря этому, я узнал, что у Transmission есть отличный протокол для удалённого управления. Так и родилась идея написать собственный удалённый клиент — прежде всего для собственных нужд.

Недостатка торрент-клиентов сегодня не наблюдается. Полки, можно сказать, ломятся от изобилия. Так почему решили управлять именно transmission-daemon?
Как оказалось, Transmission — самый подходящий торрент клиент для медиа плееров, NAS'ов, роутеров и прочей маломощной техники. Как я уже говорил, он сейчас работает в моём медиаплеере, а скоро переселится в новый NAS.

Посчитать программы, написанные на Pascal, в моей Ubuntu очень легко. Она всего одна. Чем обусловлен выбор языка и какой ценой далась кроссплатформенность?
В своей основной работе я программирую в среде Delphi на языке Pascal уже около 15 лет. До этого я также программировал на Turbo Pascal. Поэтому Pascal — это мой любимый язык программирования, хотя, в разное время, я программировал на Ассемблере, C, C++, Basic, Java, PHP.
Я участвую в разработке компилятора Free Pascal. Порт FPC для Windows CE — это моя работа.
Вот отсюда и выбор средства разработки. Мне давно хотелось написать что-то кроссплатформенное и заодно проверить, как с этим справится среда Lazarus (open source аналог Delphi). В итоге все вышло. Пришлось немного побороться с глюками Lazarus на разных платформах, но я к этому был готов и опыта для борьбы у меня предостаточно :)

Сложилось мнение, мол, Pascal годится только для обучения. Вы попробовали несколько языков, но свой выбор не изменили. В чём причина? Сломайте стереотип :-)
Это, конечно же, миф :) По синтаксису Pascal проще чем C/C++ — только из-за этого его и используют для обучения. Так как Pascal компилируется в машинный код, то он стоит на той же ступеньке, что и C/C++. Все что можно сделать на C/C++ можно сделать и на Pascal, и наоборот.
В Pascal мне нравятся такие вещи, которых нет в C/C++:

• Встроенный строковый тип string;
• Высокая скорость компиляции.

Проблемы и запросы пользователей разных ОС отличаются или все хотят примерно одинаковые функции?
В основном все хотят функционала общего для всех платформ. Но есть и запросы специфических вещей, например, поддержка Growl на Mac OS X. Т.к. я не пользуюсь Mac OS X, то поддержка таких вещей меня не интересует. Оставляю реализацию этого пользователям. Патчи всегда приветствуются.

На мой взгляд, сейчас мало написать программу и разместить её на специальном ресурсе. Никто не будет ковырять исходники просто, чтобы скомпилировать и проверить программу. Народ требует бинарных сборок, пакетов для популярных дистрибутивов, вики-страницы, «живой» багтрекер и прочие тому подобные вещи. Transmission-remote-gui в этом плане оставляет приятное впечатление. А вопрос нехитрый: насколько важна сопроводительная работа и как вы с ней справляетесь?
Сопроводительная работа очень важна. Многие думают, что стоит только создать проект с открытым кодом и все сразу кинутся помогать с сайтом, кодом, и тд. Такого можно ожидать только через много лет и только для очень популярных проектов. Для большинства проектов его основатель должен делать всё сам.
Раз в несколько месяцев я выкраиваю время на выпуск новой версии. На вопросы стараюсь отвечать сразу. Поддержка пользователей очень важна. Даже если он написал «Спасибо за отличную программу», то появляется стимул развивать её дальше. Также хороший стимул дают финансовые пожертвования, хотя и хватает их всего лишь, чтобы разок попить пива :)

Долгое время Google Code ругали за отсутствие распределённых систем контроля версий. Но вот ребята добавили hg, а разработчики продолжают дёргать svn :-) Интересно узнать ваше мнение как про системы контроля, так и выбранную площадку.
Google Code был выбран, в первую очередь, из-за скорости работы самого сайта и SVN на нём. До этого у меня был опыт работы с SourceForge — скорость меня очень огорчала. Теперь же я вижу, что и поддержка проекта на Google Code удобнее чем на SourceForge.
Я продолжаю пользоваться SVN, так как для моих проектов его хватает с головой. Для очень больших проектов, наверное, лучше использовать hg или git.

Какие новшества запланированы в ближайших версиях?
Только что вышла версия 3.0, где реализовано много новшеств. Определенных планов на новые версии пока нет — исправлять баги, реализовывать новые функции будущих версий Transmission и популярные запросы пользователей на сайте.

Спасибо за уделённое время. Успехов в намеченных замыслах!
Спасибо :)

Tweet