Макс Лапшин

Немножко хочу рассказать про документацию на нашем https://flussonic.com/doc/

Основные идеи, которые сейчас я принял при развитии документации такие:

* документация — такой же кодифицируемый кусок продукта, как и сценарий тестирования

* надо учиться проверять документацию на полноту и достоверность

* тестировщик, техпис и продакт делают в некотором смысле схожие действия с софтом: проходят по определенным сценариям

Текущий статус

=============

Сейчас это по 2 мегабайта текста на английском  и русском, 280 файлов каждого языка, порядка 150 тыс слов/около миллиона знаков

Документация по большей части референс, т.е. сухое описание фич, их настроек и т.п.

Сейчас она обрабатывается на руби маркдауном, потом написанным нами xml процессором, который делает ряд вещей:

1. проставляет title будущим HTML-ям и метатеги для SEO

2. обрабатывает инклюды

3. обрабатывает ссылки

4. делает магию с документационными тестами

5. делает магию с интеграцией с хелпом в приложении

Документационные тесты

======================

Документационные тесты — я не видел описания подобной идеи, придумали сами, скорее всего многие такое уже делали.

Идея в следующем: у нас в документации есть сниппет кода/конфига, значит надо быть уверенным в том,

что он правильный и рабочий.

Решение: рядом с документацией кладем тест, который по нужному идентификатору извлекает из текста документации

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

Если что-то разошлось, мы узнаем.

Мы в этом году сделали и сейчас начинаем продавать свою собственную железку: аппаратный транскодер.

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

Я не буду пока что рассказывать про все страдания от процесса разработки железа, но хочу немного поделиться про софтверную часть того, что называется appliance (как это будет по-русски?)

В отличие от продажи софта на сервер, который админим не мы, тут всё начиная от ядра готовим мы.

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

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

Во-вторых, всплыла пачка интересных сложностей с линуксом.

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

При этом навыки программиста помогают делать простые и стабильные решения (типа положить файлик в /etc/что-то-там.d вместо sed-редактирования /etc/что-то-там)

В-третьих, очень непривычна невозможность внятного полноценного тестирования иначе кроме как руками.

Очень во многом эта работа перекликается с нашим Flussonic Iris (напоминаю, это прошивка для IP-камер, таким занимается буквально пара команд в стране). Нужно постоянно решать, как пользоваться линуксом: использовать системный код или писать своё.

В прошлом году я наконец смог выделить нормальное количество денег на разработку своей прошивки для IP камер. Эта идея у меня была года так с 2013, но не было сил и денег на это.

Теперь у меня целая команда занимается этим проектом и мы активно продвигаемся.

Ситуация такая: на сегодняшний день в хроме/лисе нельзя зайти ни на одну IP камеру из известных мне и посмотреть, чего она видит. Есть некоторые российские проекты типа polyvision или trassir, которые пихают flash, но они опоздали на несколько лет. Флеш уже списан, похоронен и перестал смрадно вонять.

Наша прошивка для IP камеры судя по тому что я знаю первая в мире, которая позволяет получить видео без задержки в HTML5 интерфейсе даже без webrtc.

Сейчас мы собираем прошивку, которая встает на камеры на hi3516a + imx178, но в планах конечно вся линейка хайсиликона.

Для затравки видео из веб-интерфейса: