Проект "Горная утка"

Или как мы участвовали в разработке программного продукта для простых юзеров — тот самый классический «shareware», 2018й год.

Про другие наши интересные проекты можно прочитать тут, тут и тут.

Еще тут и тут.

Mountain Duck

Это будет необычная история, поскольку в этот раз рассказ пойдет о небольшом коммерческом desktop-приложении для широкой аудитории — для простых пользователей.

Это не ваши любимые CRUDы, не веб с микросервисами и не «кровавый энтерпрайз», готовый проглотить любое тормозное говно, лишь бы работало на заранее согласованном корпоративном Dell.

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

Проще говоря простых людей на такой проект никогда не позовут.

Продукт

«Горная утка» реализует одну очень простую для конечного пользователя, но нереально сложную технически задачу:

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

Речь идет в первую очередь про Google Drive, Amazon S3 и подобные онлайн-сервисы:

Как это выглядит на Mac (современная версия):

Продукт частично открыт, открытую версию можно посмотреть на Github.

Технические особенности

Проект использовал достаточно нетривиальный подход, слабо доступный для понимания и осознания простыми смертными зумерами:

Была еще и небольшая программная часть, отвечающая за непосредственно «прикидывание» для пользователя файловой системой, которая была реализована на более классических для такого рода приложений C++/Objective-C, но с точки зрения основной логики это были лишь вызовы функций API.

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

Кратко — потому что по теме managed языков пишут серьезные научные работы.

Суть в том, что любая программа содержит ошибки, тем более если она большая и сложная, тем более если речь про десктопное ПО и графический интерфейс.

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

И они там есть, в большом количестве.

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

Что такое «ошибка» с точки зрения пользователя?

Ну например вот такое:

Собственно после этого диалога следует аварийное завершение программы, а пользователь начинает осаждать техподдержку с криками «не работает!»

Но самое веселое происходит потом:

поиск проблемы, отладка и исправление — в чисто нативном приложении сильно сложнее чем при наличии managed-слоя

Поэтому подобный проект, будучи реализованным на одном только C++ вряд ли бы смог завоевать столь широкую аудиторию.

Кстати подобным образом устроены практически все современные сложные десктопные системы:

Проблемы и реалии

Если открыть раздел Issues открытой версии продукта, можно легко и быстро понять ключевую проблематику:

Как видите большинство багов имеют отношение к тем или иным особенностям работы приложения в различных средах:

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

C 2018го года ничего особо не изменилось и все подобные проблемы являются «темной» обратной стороной выбранного подхода:

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

Еще это всегда будет тормозить.

Причем провисания в скорости обязательно будут влиять и на конечные приложения, яркий пример — упавший Adobe InDesign, словивший падение при попытке чтения файла через «утку»:

Тестовое задание

Достаточно очевидно, что участие в подобном проекте требует начального подтверждения навыков, поскольку основные компетенции всегда и обязательно будут на стороне in-house команды.

Как-то так выглядело тестовое задание, с решения которого было начато сотрудничество:

Bug: As you know Mountain Duck (MD) integrates a NFSv4 server [1] (on MacOS). We have an issue with sequences ids when opening and saving multiple Pages/Number documents on the same mount. For some reason our NFS server thinks that the ids are out of sequence. That only happens when opening and then saving multiple documents on the same mount. A single document works fine.

Goal: Analyse where the issue sits. It could be an issue with the MacOS NFS client which we know that it’s not rock solid but it could be also an issue in the dCache NFS implementation or our fork that contains a few workarounds for the MacOS NFS client. If it’s a dCache issue we can report or your directly fix the issue if it’s obvious. Otherwise they are quite fast in fixing bugs. In case it is a NFS client issue you need to find a workaround to fix the issue.

Вот так выглядел процесс отладки и поиска решения для тестового задания:

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

Типовая задача

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

На свете есть такой специализированный редактор TeXShop для Mac:

TeXShop was developed by American mathematician Richard Koch. It was modeled on NeXTstep's bundled TeXview.app and developed for the then new macOS user interface Aqua and capitalized on the native PDF support of that version of the Macintosh operating system,[1] which was itself based on NeXTSTEP's successor OPENSTEP.

Как видите редактор с историей, уходящей в далекое прошлое, очень известный и популярный:

The program (then version 1.19) won the 2002 Apple Design Award of Best Mac Open Source Port[2] for its capability to display scientific and technical documents created in TeX format.

И. он работал неправильно при сохранении файлов в облако через «утку»:

Как нетрудно догадаться, исправлять сам TexShop (несмотря на то что он открытый) никто бы не дал, а его разработчики на багрепорт вроде:

ваша программа неправильно работает с удаленным облачным хранилищем, зацепленным через наше приложение

в лучшем случае покрутили бы пальцем у виска.

Поэтому пришлось подгонять реалии под ожидания стороннего приложения — фактически вставлять специальную логику в «утку», закрывающую потребности именно этого клиентского приложения.

Еще один забавный скриншот с тех лет, так выглядел отладочный документ для обкатки процесса сохранения:

Эпилог

Участие в этом проекте, дало нам (помимо нового опыта) возможность посмотреть на проблематику обмена файлами под другим углом и в какой-то мере подтвердило правильность выбранного подхода с уже нашим собственным проектом — Телепортой:

Еще надеюсь эта статья будет хорошей и очередной иллюстрацией наших компетенций во всех аспектах процесса разработки ПО.

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