Abstract

Сразу скажу, контрибутинг не обязательно означает написание кода. Важную роль играет тестирование, написание багрепортов, обсуждение актуальности фич и локализация. Но поскольку я программист, мне хотелось большего. В последние пару месяцев я наконец-то начал писать код для uTox’а, а не только тестировать и заводить issue. Это был долгий путь.

Introduction

uTox это легковесный Tox-клиент. Опенсорс, end-2-end, p2p — это всё про него (подробнее: сайт и вики). Написан на чистом C с минимумом зависимостей.

Я услышал и начал пользоваться uTox’ом в конце 2014 года, а первые issue начал заводить в конце 2015 года.

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

И лишь этой весной я решил довести дело до конца, и у меня всё получилось.

Methods

Set up

Итак, я хочу что-то исправить в коде. Прежде всего мне нужно было научиться собирать проект uTox’а хотя бы под свою ОС. И с этим у меня были большие проблемы.

Дело в том, что uTox пилят под линуксом. И из разработчиков никто реально не запаривался тем, чтобы он собирался под Windows. В смысле работать он работает, но собирается всё равно под линуксом. Да, были/есть инструкции, как его собирать с помощью Cygwin+MinGW, но у меня ни разу так и не получилось, хотя я пробовал много раз.

В качестве сборочной системы используется CMake, и я подумал, а давай-ка я просто соберу проект под Visual Studio и буду спокойно работать в ней. Хорошая была идея. Короче, проект под студию создавался, но с зависимостями я так и не справился. Freetype, pthreads и ещё парочка доставили мне много боли, и никакого результата на выходе я не получил.

Раз гора не идёт к Магомету, подумал я и поставил Ubuntu 16.04 в виртуалку под VBox. И после нескольких часов любви со сборкой всех зависимостей, я наконец-то собрал первый раз uTox!

Environment

Пару слов, как у меня всё настроено. К моему большому сожалению, для Linux&C-разработке нет IDE уровня Visual Studio. Увы. Я пробовал NetBeans, но она слишком убогая, извините. В итоге пришлось использовать SublimeText2 в качестве редактора + плагин для документации DoxyDoc.

Мне очень стыдно, но пока я так и не прикрутил себе дебаггер. Нашёл пару плагинов для связки GDB+Sublime, но сходу не разобрался в настройках, а из коробки оно не работает.

Так что большую часть времени я просто пишу код, для отладки пользуюсь логом, и только если ОЧЕНЬ прижмёт запускаю NetBeanse и дебажу в нём.

Development

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

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

Было-стало:

Далее я продолжил наводить красоту и занялся Assembly Info. И был неприятно удивлён тому, насколько сложнее это делается на C, чем на C#. Пришлось потратить некоторое время, разбираясь с магией WinAPI касательно свойств файла.

После исправления ещё пары мелких багов я решил взяться за что более-менее серьёзное. Поискав среди issues и вспомнив своей опыт, я выбрал поддержку Юникода при передаче файлов. В чём была проблема? Под Windows нельзя было получить или принять файл, если его имя содержало не-ASCII символы. Это заняло у меня намного больше времени, чем я рассчитывал, и, на данный момент, ревью я так до конца не прошёл и изменения не приняли. Но я, в любом случае, хочу довести это до конца, не в этом релизе, так в следующем, а после взять небольшую паузу и пересмотреть свои взгляды на жизнь.

Community

Разработка ведётся на гитхабе, в качестве инструмента для ревью используется Reviewable. Последний коммит (мёрдж-коммит в том числе) в PR, а лучше все коммиты должны быть подписаны GPG-ключом (добавленным и на гитхаб). Для мёрджа нужно получить не менее трёх одобрений PR со стороны команды.

Дискуссии про конкретные баги/фичи и в целом ведётся либо в issue, либо на канале utox в IRC. В целом команда адекватная и доброжелательная, особенно к новичкам. Чем дольше ты участвуешь в проекте, тем больше с тебя спрашивают любят на ревью.

Results

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

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