Полные результаты по этим трём вопросам:
В последнем вопросе собирались емейлы участников, они не публикуются.
Полные результаты по этим трём вопросам:
В последнем вопросе собирались емейлы участников, они не публикуются.
Бесспорный лидер в темах - “Архитектура программ. Лучшие практики по высокоуровневому проектированию”. За ним - “Кросс-компиляция. Компиляция под другие архитектуры и ОС”.
По предложенным статьям лидер - “CI для Rust. Travis, AppVeyor, Circle, а также Homu, nightli.es, Coveralls, деплой документации. С примерами скриптов”. Второе место - “Кросс-компиляция Rust. Из-под linux в windows и обратно. Требования и настройка окружения. Автоматизация сборки под разные платформы”.
Теперь про то, что с этими результатами делать.
Все хотят знать про архитектуру и проектирование, но я один не смогу написать по этой теме что-то значимое, что ещё не написано в англоязычных источниках (и частично переведено у нас).
Кросс-компиляция - большая и сложная тема. Я хочу заняться ей позже.
План статьи про кросс-компиляцию в целом получился странный - я его скопировал из GitHub (#38) и сильно не задумывался. Я думаю, кросс-компиляция между ОС не стоит того - проще собирать сразу на целевой платформе. Кросс-компиляция под другую архитектуру - другой вопрос.
Таким образом, сейчас я буду писать про CI для Rust, т.к. про это уже есть достаточно конкретный план и он достаточно популярен.
По мере проработки плана для статьи про CI обнаружил следующее.
Текущий план для статьи про CI охватывает слишком много разных вещей.
Travis настраивается тривиально. Про это можно написать очень коротко.
Circle CI и AppVeyor не настраиваются тривиально. Там нужны отдельные хитрые скрипты.
Homu в его облачном варианте больше не работает - нужно хостить на своём сервере. В любом случае, его настройка довольно сложна.
nightli.es не сильно актуален для Rust, т.к. повсеместный semver и правильное указание версий устраняют необходимость проверять каждую опубликованную версию зависимостей.
Coveralls не поддерживает Rust из коробки, и там тоже надо пару раз присесть, чтобы настроить. Его поддерживает travis-cargo, но это штука, несовместимая с другими всеобъемлющими решениями для CI (например, trust). Зато можно воспользоваться tarpaulin (хотя он только что вышел и сырой).
Задача автоматического развёртывания документации в простом случае решена - docs.rs сам всё делает, если крейт лежит на crates.io.
Я не хочу сказать, что “ой, тут про всё оказывается писать сложно, поэтому писать не хочу”. Я не хочу писать про кучу сложных, слабо связанных вещей в одной статье. Поэтому я собираюсь сделать цикл статей про CI для Rust, вместо одной большой статьи.
Обновлённый план статей таков:
Этот план отдаёт предпочтение Open Source и разным технологиям для энтузиастов.
В случае с промышленным использованием Rust план был бы другой:
Я хочу начать со статей для энтузиастов. Таким образом, буду писать “1. Как настроить сборку и тестирование для Open Source проекта на Rust под Linux с помощью Travis”
Можно поспорить, нюансов тоже хватает. В идеале-то хотелось бы настроить так, чтобы билд собирался побыстрее, а не просто как-нибудь. С нашим проектом на пару граблей наступили, например, с sudo: false
док-тесты рандомно фейлились по таймауту. Новая бета-фича “build stages” никакого выигрыша не принесла, а вот “build matrix” таки помогает ускорить сборку. Подозреваю, что есть и другие интересные моменты.
Кстати, спасибо за отзыв. Увидел у вас несколько интересных вещей, постараюсь про них рассказать в ближайшее время.