Скрам -- это про отсутствие линейного менеджера и групповую динамику (Скрам-мастер -- не менеджер).
Если есть менеджер, то это уже не скрам (скрам -- организационный фреймворк вокруг расщепления руководителя проекта на скрам-мастера и владельца продукта).
Перечисленные причины выбора скрам странные, они все как раз больше за Канбан.
Да, Канбан часто лучше, т.к. мало кто готов к Скрам-мастерам.
Короче тут не про то как выстроить экосистему ориентированную на kotlin и его специфику
Да, не было цели взять Kotlin + всё, что только для него написано, и посмотреть как это будет. Выбор компонентов кратко описан.
От спрингбута уже плохеет если честно. 7 лет назад сменили Java на kotlin. И через год весь этот спринг, и его Бут из стека ушли в небытие. Для экосистемы kotlin полно микро фреймворков и di. Мы используем. Ktor и kodein. ... а скорее как впихнуть kotlin в этот жутковатый и полный мемов про оверинжениринг шаблон со спрингами и прочим
Я не пользовался ни Ktor, ни kodein. Возможно, из-за привычки не вижу проблем со спрингом и прочим. Можете раскрыть свою мысль чем стек Ktor и kodein лучше?
В идеале, конечно, форкнуть репозитарий и показать как это будет. Тогда можно будет "пощупать", понять плюсы/минусы. Мы же все-таки про код, а не теории. Конечно, я понимаю, что это наверняка займет несколько дней, поэтому вероятность не очень большая.
Как железо можно присмотреться к Orange Pi R1 Plus LTS: новый (легко купить без поисков б/у) безвентиляторный с корпусом стоит 2.9тр с Али. Нужно только блок питания добавить (можно взять от старого телефона, если там разъем usb, т.к. мало требуется). Он слабее, но и ест меньше. Мощности на статику должно хватить.
Бесперебойник вряд ли нужен, но это у кого как.
Но на практике VPS 200р/мес именно для хостинга сайта выглядит лучше (туда и кулифай можно поставить).
Дома лучше хостить что-то вместо SaaS-решений. Например, Nextcloud или Gitea. При это уже что-то на x86 лучше: мощнее и точно ПО запустится. У меня, например, не запустился офисный редактор под ARM в Nextcloud.
Генерация -- это хорошо, но еще лучше без нее (как в openapi), т.к. ее либо руками нужно запускать, либо она отнимает время при каждой сборке. Плюс, сложности при внесении изменений. Например, какое-то вычислимое поле в DTO сделать или что-то такое.
Из дополнительных бонусов - можно все согласовать с фронтендерами ДО того, как написал GraphQL сервис. Потому что разработка начинается с написания схемы.
Вот тут я чувствую свое бессилие в объяснении позиции. Этот аргумент часто употребляется, но, как по мне, это не отличается.
Да, начинается со схемы. Но где ее писать? Я предпочитаю в IDE в виде Котлин-кода. Писать код и получить из него схему не дольше. Тут я говорю про OpenAPI и GraphQL в Quarkus, в Spring ситуация с GraphQL другая, т.к. подход не поддерживается. Так же этом может быть точнее, особенно если какие-то классы с данными уже есть.
Далее можно обсуждать спеку в формате GraphQL. Обычно ее приношу я. Изменения после совещания легко отследить и внести -- обычно никаких проблем на данном этапе нет.
В принципе, если бы мне какие-нибудь бизнес-аналитики приносили GraphQL-спеку, то да, я бы генерировал из нее код. Разово или на постоянной основе зависит от того обновляли бы они его с компьютерной (а не человеческой) точностью или нет.
я недавно смотрел какой-то репозитарий с ним, и Idea не понимала, что это тесты. Возможно, это как-то решается, но не занимался.
так как на проектах часто не один, то обычно лучше использовать более стандартные технологии
я когда-то занимался Rails и он напоминает https://rspec.info/ (что хорошо). В общем, да, нужно на практике попробовать будет получаться лучше или нет.
testcontainer в примере есть.
kotlin-logging: у текущего api такое же и в проде настроено, чтобы JSON был. Так что, в принципе, ничего не поменяется ни как писать логи, ни по функционалу (JSON). За ссылку спасибо -- если что-то пойдет не так, то можно и на нее перейти.
Schema First (и в частности для GraphQL):
Тут у меня как раз противоположный опыт, предпочитаю что-то типа swagger: делаю контроллер на Котлине, а схема генерируется динамически. Это никак не мешает обсуждать схему, т.к. чтобы ее сгенерировать реализацию писать не нужно: просто код контроллера. В коде быстрее и удобнее писать: привычный редактор со всеми вспомогательными штуками, медленнее в коде точно не получается. Более того, можно какой-нить встроенный UI (типа swagger ui) использовать и сделать какие-нибудь заглушки с данными сразу. Если из самого кода Котлина информации не хватает, то можно добавить аннотациями. Так что на любое совещание могу принести схему.
В схеме крайне важна актуальность, а на практике, если пишут схему вручную, то она часто с опечатками (невалидная) и устаревшая. А так никаких вопросов где схема и актуальная ли она (в Schema First часто заводят отдельный репозитарий под схему, хотя это не обязательно так).
Так что я в раздумьях как лучше для Spring Boot GraphQL написать генератор схемы. Проще всего kapt и сохранять в файловую систему -- тогда не будет требоваться изменений на стороне Spring Boot GraphQL. Лучше всего динамически как в OpenAPI (найти схему через рефлексию и передать ее в Spring Boot GraphQL), но нужно будет разбираться во внутренностях Spring Boot GraphQL, чтобы интегрироваться. Посмотрим когда до этого руки дойдут.
Исключением является SQL (тут schema first с генерацией jOOQ рекордов, но, к сожалению, пока что без генерации JPA entity -- руки не дошли поразбираться что сейчас есть для этого), т.к. он гораздо сложнее OpenAPI/GraphQL и крайне важен для производительности.
Наверное, для меня OpenAPI/GraphQL вторичны: если что-то Котлин не может, то это проблема OpenAPI/GraphQL, а не Котлина. А для SQL наоборот.
Не понял мысль. Джук тем и хорош, что позволяет кодить в разных стилях. Хочешь - через DSL в стиле JDBC-темплейтов. Хочешь - через рекорды в стиле JPA. С ним и OLTP и OLAP элементарно пишется. Плюс фреймворк следует дао "явное лучше неявного".
Чтобы не читать: Jooq мне в целом нравится. Поддержка реактивности и Котлина в нем еще недоделана (хотя и есть, ощущение беты по фичам, не по стабильности). Больше всего не нравятся все nullable-поля в рекордах -- политика партии. В целом, предпочитаю Spring Data Repository для большинства случаев (когда хватает просто методов без всяких запросов и аннотаций) и jOOQ для сложных случаев (т.к. позволяет полностью использовать возможности БД).
ktor
Он выглядит неплохо, но мне пока что непонятны его преимущества. Spring дефолт и все знают. Quarkus быстрый и эффективный, поддерживается RedHat, но его уже догнал Spring. Если просто другой синтаксис, то не очень интересно. При переходе всегда дополнительные проблемы и нужно понимать из-за чего страдать).
Так я и не предлагал выкинуть интерфейсы из языка. Тем более, если что-то делается для готового фреймворка (стартер, например), то понятно, что нужно выполнять требования фреймворка. Так что полностью с вами согласен).
Интерфейсы для инверсии зависимостей на практике не нужны. По крайней мере в JVM. Можно впрыскивать (какое слово) зависимость по самому классу, а не по интерфейсу. И ничего в этом страшного нет. Если вдруг действительно понадобиться интерфейс или рефакторинг, то современными инструментами он делается без проблем.
Мок-реализация делается с помощью соответствующих библиотек и ей интерфейс тоже не нужен. Наверное, можно придумать такую организацию тестов, когда действительно будет нужно, но зачем?
Пытался пользоваться mapstruct без тестов и были проблемы. Тестами покрываются не код самого mapstruct, а аннотации маппинга (и их отсутствие). Напортачить там время от времени легко.
В итоге, сейчас в Котлине mapstruct вообще не пользуюсь -- проще самому написать.
Я все-таки склоняюсь к Code First варианту (в экосистеме Kotlin/Java). При этом нет указанных в статье проблем:
1. Во многих (особенно, в крупных) проектах, в проектировании API, помимо разработчиков, участвуют ещё несколько человек: архитекторы, системные аналитики, QA-инженеры, заинтересованные лица из других команд.
Обсуждать можно по swagger ui. Записывать решения как угодно (любой псевдокод подойдет), а реализацию обновит один из программистов за несколько минут сразу после совещания.
Во многих (особенно, в крупных) проектах, используются устаревшие языки или фреймворки, для которых просто не существует генераторов OpenAPI-спецификаций. В итоге, часть API оказывается без документации (и как правило это очень важные API, работающие в компании уже много лет!).
За другие платформы не скажу -- в деталях не знаю, но на JVM прекрасно работает. Нельзя назвать Java чем-то новомодным или для маленьких проектов.
3. Генераторы OpenAPI-спецификаций нередко содержат ошибки, которые порой не позволяют сгенерировать то, что нужно
Все API так описываю, на практике не встречался. Если даже встречусь, то есть несколько вариантов обхода:
самый простой -- добавить детали в описание
сложнее -- написать промежуточный api, который бы делал нужные манипуляции
еще сложнее -- самому исправить генератор
Опять же -- для меня это теория, т.к. багов не припомню.
4. OpenAPI-генераторы способны сгенерировать только часть документации. Но ведь надо еще добавить подробные описания, примеры использования, примеры сообщений (особенно это важно в крупных проектах). Всё это нужно делать вручную и каким-то образом заталкивать в программный код, чтобы потом, на его основе, генератор создал полноценную спецификацию.
Это просто неправда. Общую информацию можно добавить через специальный бин, информацию на конкретный элемент соответствующими аннотациями. Более того, можно через настройки сделать несколько вариантов спецификации -- например, с внешней авторизацией через API-gateway и с внутренней для внутренних запросов.
Что же касается JSIGHT -- мне все равно -- если станет популярным, то из тех же аннотаций будет генерироваться и эта версия спеки. А руками в чате или на доске все равно проще буду писать (например, обычно без 200).
При этом добавлю, что, как все на свете, OpenAPI имеет ограничения. Особенно плохо с генерацией клиентов (а не спецификации) -- их писали очень странные люди, так что многие клиенты по спецификации не генерируют. Но это другая история.
Если серьезней, какой-то стандартный (детский, т.к. организации с опытом уже должны были бы их пройти) набор проблем управления разработкой ПО и довольно наивные пути их решения. В кучу смешаны довольно много процессов, например оценка, планирование работ (взаимосвязи команд, отпуска и прочее) и, собственно, управление (добавление новых задач по ходу и тп).
Если у вас водопад, то для этого есть свои практики. Оно даже иногда работает, несколько раз был такой успешный опыт. Если не водопад, то тоже есть свои подходы.
"В идеальном скрам-мире такие задачи не берутся в спринт" -- более чем странное заявление, т.к. agile -- это все-таки про гибкость. Если надо, то берутся (и agile не простив этого ни в коем случае, перечитайте принципы от которых все строится). Просто, это приводит к перезапуску спринта после этих задач. Или снятию обязательств команды к задачам в спринте. Ну и разбору на ретро как это можно улучшить (если часто происходит) -- уменьшать размер спринта, переключиться на канбан или оставлять запас времени на такие задачи (и отдельные задачи в спринте, если этот риск не сработал).
Уточню: под коробкой я подразумевал customer device, т.е. максимально не требующий технических знаний. Типа Synology или CasaOS. А так да, ваш вариант хороший и рабочий.
ну что написать? да, знаю... если все детали в каждом сообщении описывать, то можно в этих деталях закопаться. при этом суть комментария остается: NC и аналоги позволяют работать по децентрализованному принципу, а WebDAV нет
хранения и доступа к файлам из любого места (не люблю я эти nextcloud, проще через WebDAV/браузер зайти куда надо)
Тут основное отличие в центролизованности / децентролизованности: NextCloud все хранит на каждом клиенте и синхронизируется когда есть связь -- в этом свои и плюсы, и минусы.
Если вы решили использовать "Portainer" вместо NAS - то вы просто до конца не разобрались что для чего нужно (спойлер : портейнер управляет контейнерами аля докер или кубер . У меня он стоит, но правлю я всё ручками).
Это понятно. Мне не нужен NAS. Мне нужна замена публичных облаков (Google Docs, Dropbox, ...). И удивило, что такие коробочные замены называются NAS на практике: во все NAS обычно еще есть возможность поставить OwnCloud / NextCloud или там что-то похожее свое.
В целом, действительно очень похожие по идеологии системы. В деталях различия (вместо Микротиков Кинетики -- они тоже все это умеют, Gitea+Drone место Gitlab и тп), но это норм).
В общем, если у него все обзоры такие — то не надо его смотреть.
Я не смотрел других видео этого же товарища, не знаю. Понятно, что он не нашел магазин приложений, который есть.
Изначально не попробовал сам, т.к. не хотелось всю систему переставлять. Да, наверное, попробую на выходных. Мне вся эта визуальная настройка хранилища как раз не особо нужна, нужно чтобы стабильно устанавливались и работали многослойные приложения (типа само приложение + редис + постгрес + понятно как делается бекап и идет восстановление из него).
Про Mikrotik: в статье предупреждаю, чтобы народ случайно для фана не купил его домой.
Скрам -- это про отсутствие линейного менеджера и групповую динамику (Скрам-мастер -- не менеджер).
Если есть менеджер, то это уже не скрам (скрам -- организационный фреймворк вокруг расщепления руководителя проекта на скрам-мастера и владельца продукта).
Перечисленные причины выбора скрам странные, они все как раз больше за Канбан.
Да, Канбан часто лучше, т.к. мало кто готов к Скрам-мастерам.
Спасибо за комментарий и что поделились опытом).
Да, не было цели взять Kotlin + всё, что только для него написано, и посмотреть как это будет. Выбор компонентов кратко описан.
Я не пользовался ни Ktor, ни kodein. Возможно, из-за привычки не вижу проблем со спрингом и прочим. Можете раскрыть свою мысль чем стек Ktor и kodein лучше?
В идеале, конечно, форкнуть репозитарий и показать как это будет. Тогда можно будет "пощупать", понять плюсы/минусы. Мы же все-таки про код, а не теории. Конечно, я понимаю, что это наверняка займет несколько дней, поэтому вероятность не очень большая.
Спасибо за найденную статью)
Как железо можно присмотреться к Orange Pi R1 Plus LTS: новый (легко купить без поисков б/у) безвентиляторный с корпусом стоит 2.9тр с Али. Нужно только блок питания добавить (можно взять от старого телефона, если там разъем usb, т.к. мало требуется). Он слабее, но и ест меньше. Мощности на статику должно хватить.
Бесперебойник вряд ли нужен, но это у кого как.
Но на практике VPS 200р/мес именно для хостинга сайта выглядит лучше (туда и кулифай можно поставить).
Дома лучше хостить что-то вместо SaaS-решений. Например, Nextcloud или Gitea. При это уже что-то на x86 лучше: мощнее и точно ПО запустится. У меня, например, не запустился офисный редактор под ARM в Nextcloud.
Генерация -- это хорошо, но еще лучше без нее (как в openapi), т.к. ее либо руками нужно запускать, либо она отнимает время при каждой сборке. Плюс, сложности при внесении изменений. Например, какое-то вычислимое поле в DTO сделать или что-то такое.
Вот тут я чувствую свое бессилие в объяснении позиции. Этот аргумент часто употребляется, но, как по мне, это не отличается.
Да, начинается со схемы. Но где ее писать? Я предпочитаю в IDE в виде Котлин-кода. Писать код и получить из него схему не дольше. Тут я говорю про OpenAPI и GraphQL в Quarkus, в Spring ситуация с GraphQL другая, т.к. подход не поддерживается. Так же этом может быть точнее, особенно если какие-то классы с данными уже есть.
Далее можно обсуждать спеку в формате GraphQL. Обычно ее приношу я. Изменения после совещания легко отследить и внести -- обычно никаких проблем на данном этапе нет.
В принципе, если бы мне какие-нибудь бизнес-аналитики приносили GraphQL-спеку, то да, я бы генерировал из нее код. Разово или на постоянной основе зависит от того обновляли бы они его с компьютерной (а не человеческой) точностью или нет.
да, нужно попробовать kotest, может будет лучше
Спасибо за комментарий).
kotest:
я недавно смотрел какой-то репозитарий с ним, и Idea не понимала, что это тесты. Возможно, это как-то решается, но не занимался.
так как на проектах часто не один, то обычно лучше использовать более стандартные технологии
я когда-то занимался Rails и он напоминает https://rspec.info/ (что хорошо). В общем, да, нужно на практике попробовать будет получаться лучше или нет.
testcontainer в примере есть.
kotlin-logging: у текущего api такое же и в проде настроено, чтобы JSON был. Так что, в принципе, ничего не поменяется ни как писать логи, ни по функционалу (JSON). За ссылку спасибо -- если что-то пойдет не так, то можно и на нее перейти.
Schema First (и в частности для GraphQL):
Тут у меня как раз противоположный опыт, предпочитаю что-то типа swagger: делаю контроллер на Котлине, а схема генерируется динамически. Это никак не мешает обсуждать схему, т.к. чтобы ее сгенерировать реализацию писать не нужно: просто код контроллера. В коде быстрее и удобнее писать: привычный редактор со всеми вспомогательными штуками, медленнее в коде точно не получается. Более того, можно какой-нить встроенный UI (типа swagger ui) использовать и сделать какие-нибудь заглушки с данными сразу. Если из самого кода Котлина информации не хватает, то можно добавить аннотациями. Так что на любое совещание могу принести схему.
В схеме крайне важна актуальность, а на практике, если пишут схему вручную, то она часто с опечатками (невалидная) и устаревшая. А так никаких вопросов где схема и актуальная ли она (в Schema First часто заводят отдельный репозитарий под схему, хотя это не обязательно так).
Так что я в раздумьях как лучше для Spring Boot GraphQL написать генератор схемы. Проще всего kapt и сохранять в файловую систему -- тогда не будет требоваться изменений на стороне Spring Boot GraphQL. Лучше всего динамически как в OpenAPI (найти схему через рефлексию и передать ее в Spring Boot GraphQL), но нужно будет разбираться во внутренностях Spring Boot GraphQL, чтобы интегрироваться. Посмотрим когда до этого руки дойдут.
Исключением является SQL (тут schema first с генерацией jOOQ рекордов, но, к сожалению, пока что без генерации JPA entity -- руки не дошли поразбираться что сейчас есть для этого), т.к. он гораздо сложнее OpenAPI/GraphQL и крайне важен для производительности.
Наверное, для меня OpenAPI/GraphQL вторичны: если что-то Котлин не может, то это проблема OpenAPI/GraphQL, а не Котлина. А для SQL наоборот.
Да, тут очень кратко. У меня есть 2 более развернутые заметки: https://stepin.name/technoblog/033-kotlin-orm/ и https://stepin.name/technoblog/037-jooq/ .
Чтобы не читать: Jooq мне в целом нравится. Поддержка реактивности и Котлина в нем еще недоделана (хотя и есть, ощущение беты по фичам, не по стабильности). Больше всего не нравятся все nullable-поля в рекордах -- политика партии. В целом, предпочитаю Spring Data Repository для большинства случаев (когда хватает просто методов без всяких запросов и аннотаций) и jOOQ для сложных случаев (т.к. позволяет полностью использовать возможности БД).
Он выглядит неплохо, но мне пока что непонятны его преимущества. Spring дефолт и все знают. Quarkus быстрый и эффективный, поддерживается RedHat, но его уже догнал Spring. Если просто другой синтаксис, то не очень интересно. При переходе всегда дополнительные проблемы и нужно понимать из-за чего страдать).
Так я и не предлагал выкинуть интерфейсы из языка. Тем более, если что-то делается для готового фреймворка (стартер, например), то понятно, что нужно выполнять требования фреймворка. Так что полностью с вами согласен).
Интерфейсы для инверсии зависимостей на практике не нужны. По крайней мере в JVM. Можно впрыскивать (какое слово) зависимость по самому классу, а не по интерфейсу. И ничего в этом страшного нет. Если вдруг действительно понадобиться интерфейс или рефакторинг, то современными инструментами он делается без проблем.
Мок-реализация делается с помощью соответствующих библиотек и ей интерфейс тоже не нужен. Наверное, можно придумать такую организацию тестов, когда действительно будет нужно, но зачем?
Пытался пользоваться mapstruct без тестов и были проблемы. Тестами покрываются не код самого mapstruct, а аннотации маппинга (и их отсутствие). Напортачить там время от времени легко.
В итоге, сейчас в Котлине mapstruct вообще не пользуюсь -- проще самому написать.
Я все-таки склоняюсь к Code First варианту (в экосистеме Kotlin/Java). При этом нет указанных в статье проблем:
Обсуждать можно по swagger ui. Записывать решения как угодно (любой псевдокод подойдет), а реализацию обновит один из программистов за несколько минут сразу после совещания.
За другие платформы не скажу -- в деталях не знаю, но на JVM прекрасно работает. Нельзя назвать Java чем-то новомодным или для маленьких проектов.
Все API так описываю, на практике не встречался. Если даже встречусь, то есть несколько вариантов обхода:
самый простой -- добавить детали в описание
сложнее -- написать промежуточный api, который бы делал нужные манипуляции
еще сложнее -- самому исправить генератор
Опять же -- для меня это теория, т.к. багов не припомню.
Это просто неправда. Общую информацию можно добавить через специальный бин, информацию на конкретный элемент соответствующими аннотациями. Более того, можно через настройки сделать несколько вариантов спецификации -- например, с внешней авторизацией через API-gateway и с внутренней для внутренних запросов.
Что же касается JSIGHT -- мне все равно -- если станет популярным, то из тех же аннотаций будет генерироваться и эта версия спеки. А руками в чате или на доске все равно проще буду писать (например, обычно без 200).
При этом добавлю, что, как все на свете, OpenAPI имеет ограничения. Особенно плохо с генерацией клиентов (а не спецификации) -- их писали очень странные люди, так что многие клиенты по спецификации не генерируют. Но это другая история.
Так и запишем -- в Альфу ни ногой.
Если серьезней, какой-то стандартный (детский, т.к. организации с опытом уже должны были бы их пройти) набор проблем управления разработкой ПО и довольно наивные пути их решения. В кучу смешаны довольно много процессов, например оценка, планирование работ (взаимосвязи команд, отпуска и прочее) и, собственно, управление (добавление новых задач по ходу и тп).
Если у вас водопад, то для этого есть свои практики. Оно даже иногда работает, несколько раз был такой успешный опыт. Если не водопад, то тоже есть свои подходы.
"В идеальном скрам-мире такие задачи не берутся в спринт" -- более чем странное заявление, т.к. agile -- это все-таки про гибкость. Если надо, то берутся (и agile не простив этого ни в коем случае, перечитайте принципы от которых все строится). Просто, это приводит к перезапуску спринта после этих задач. Или снятию обязательств команды к задачам в спринте. Ну и разбору на ретро как это можно улучшить (если часто происходит) -- уменьшать размер спринта, переключиться на канбан или оставлять запас времени на такие задачи (и отдельные задачи в спринте, если этот риск не сработал).
Уточню: под коробкой я подразумевал customer device, т.е. максимально не требующий технических знаний. Типа Synology или CasaOS. А так да, ваш вариант хороший и рабочий.
Оно там есть, но только в консоли: https://help.keenetic.com/hc/ru/articles/360011129420 Мне пока что достаточно.
ну что написать? да, знаю... если все детали в каждом сообщении описывать, то можно в этих деталях закопаться. при этом суть комментария остается: NC и аналоги позволяют работать по децентрализованному принципу, а WebDAV нет
ага, про бекапы и хранилища будет в следующей статье
Тут основное отличие в центролизованности / децентролизованности: NextCloud все хранит на каждом клиенте и синхронизируется когда есть связь -- в этом свои и плюсы, и минусы.
Это понятно. Мне не нужен NAS. Мне нужна замена публичных облаков (Google Docs, Dropbox, ...). И удивило, что такие коробочные замены называются NAS на практике: во все NAS обычно еще есть возможность поставить OwnCloud / NextCloud или там что-то похожее свое.
В целом, действительно очень похожие по идеологии системы. В деталях различия (вместо Микротиков Кинетики -- они тоже все это умеют, Gitea+Drone место Gitlab и тп), но это норм).
да, спасибо, сегодня как раз нашел
Я не смотрел других видео этого же товарища, не знаю. Понятно, что он не нашел магазин приложений, который есть.
Изначально не попробовал сам, т.к. не хотелось всю систему переставлять. Да, наверное, попробую на выходных. Мне вся эта визуальная настройка хранилища как раз не особо нужна, нужно чтобы стабильно устанавливались и работали многослойные приложения (типа само приложение + редис + постгрес + понятно как делается бекап и идет восстановление из него).
Про Mikrotik: в статье предупреждаю, чтобы народ случайно для фана не купил его домой.