Open source + Разработка

Основные фичи:

- микросервисная парадигма
- простой API: RPC, команды, подписки и т.п.
- транспорт данных через сокеты и вебсокеты
- легкость и быстрота: Node.js и TypeScript
- поддержка пользовательской сериализации
- поддержка пользовательской валидации рукопожатий (handshake)
- продвинутый логгер: теги, фильтры, области
- справочные материалы: документация, сниппеты, примеры
- почти нулевая конфигурация

Есть демка с примерами работы API и простенькая онлайн игра "Крестики-Нолики": как серверная часть, так и клиентская. Всё можно посмотреть, поковырять, запустить у себя и попробовать поиграть. Весь код старался комментировать, иногда даже излишне. Также есть документация с описанием всех компонентов и методов. Это всё в процессе наполнения и улучшения.

Ниже, пример WebGL билда с игрой "Крестики-Нолики".

В примере реализовано:

• старт/остановка поиска свободных игр

• простой матчмейкинг

• отправка команды хода игрока

• отправка команды выхода из игры

• обнаружение ничьей и конца раунда

• сохранение текущего счёта

Основная цель Shardy – предоставить простое бесплатное решение для создания многопользовательских онлайн игр. Вот так вот громко 😅 На это будет обращено основное внимание при дальнейшей разработке новых функций, сервисов и туторов (было бы время...).

Да, пока это голый фреймворк без полезной нагрузки в виде готовых каких-то решений, модулей, примеров игр и т.п. И да, входной порог есть, нужно уметь в Node.js и Typescript, чтобы делать серверную часть. Поэтому буду добавлять полезности по мере возможностей.

Приглашаю всех заинтересованных инди и не только, посмотреть, покрутить, примерить, потестить на своих каких-то задачах, играх, проектах, прототипах. Если будут вопросы, отвечу тут в комментах или на почту mail@mopsicus.ru.

Shardy

Shardy for Unity

Shardy Tic-Tac-Toe server

Docs

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

Кстати, можете присоединяться к разработке, проект в открытом доступе: https://github.com/SyrnikovPavel/ave_blacklist

Когда начинал разработку, даже не представлял с каким на самом деле потоком негатива можно столкнуться. Кто бы мог подумать, что у пользователей такие высокие требования к бесплатному расширению, которое люди делают в свое свободное время! Люди, будьте добрее! И не ищите подводных камней там, где просто кто-то (я, например) накосячил 🙂

А какие интересные и смешные отзывы вы слышали о себе/своем продукте? Пишите в комментариях :)

1. Безопасность: Бэкэнд помогает защитить конфиденциальные данные и токены аутентификации пользователей от атак типа MITM (Man-in-the-Middle). Он выступает в качестве защищенного шлюза между пользовательским устройством и базой данных или внешними службами, обеспечивая шифрование и аутентификацию всех данных.

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

3. Интеграция с базой данных: Бэкэнд обеспечивает бесшовную интеграцию с базами данных, позволяя динамически хранить, извлекать и обновлять данные в режиме реального времени. Это важно для приложений, которые требуют учетных записей пользователей, хранят их предпочтения или нуждаются в быстром и безопасном получении больших объемов данных.

4. Модели подписки и Freemium: Реализация услуг по подписке или модели freemium требует наличия бэкенда для выставления счетов, отслеживания использования и управления уровнями пользователей. Бэкэнд может безопасно обрабатывать платежи и подписки, обеспечивая бесперебойную работу пользователей и соблюдая требования по защите данных.

5. Масштабируемость и обслуживание: Бэкэнд позволяет более эффективно масштабировать приложение. Логику на стороне сервера можно обновлять без необходимости передавать обновления клиенту, что упрощает обслуживание и ускоряет внедрение новых функций.

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

Объяснение технического стека

• SwiftUI: Лучший вариант для нативных приложений для iOS после выхода UIKit. Он декларативен и упорядочен, а XCode является незаменимым редактором благодаря эпл. Для android код можно легко перевести на Kotlin с помощью Jetpack Compose.

• FastAPI: Выбран для бэкенда за его скорость, минимальное количество шаблонов и декларативность, редактируется с помощью превосходного Zed.dev.

• ChatGPT API: Используется в качестве большой языковой модели (LLM); выбор может меняться в зависимости от необходимости кастомизации.

• Ngrok: Реализует туннелирование с помощью простой команды CLI для выхода локального сервера в интернет.

Создание приложения для iOS

Теория: Архитектурные паттерны

1. MVVMP (Model View ViewModel Presenter):

• Model: Представляет собой структуры данных, используемые в приложении, такие как Question, Answer, Questionary и FilledQuestionary. Эти модели просты и содержат только данные, следуя принципу KISS.

• View: Отвечают только за представление пользовательского интерфейса и делегируют все данные и логику презентерам. Они не содержат никакой бизнес-логики и спроектированы так, чтобы быть простыми и сосредоточенными на рендере UI.

• ViewModel: В SwiftUI ViewModel представлена объектом ObservableObject, который служит моделью наблюдения за изменяемыми данными. Здесь нет методов и логики.

• Presenter: Presenter управляет всей логикой, связанной с модулем (экраном или представлением), но не бизнес-логикой. Он взаимодействует с доменным слоем для выполнения операций бизнес-логики, таких как взаимодействие с API или управление сохранением данных.

• Domain Layer: Этот слой содержит бизнес-логику приложения и взаимодействует с внешними ресурсами, такими как базы данных, API или другие сервисы. Он состоит из нескольких компонентов, таких как сервисы, провайдеры, менеджеры, репозитории, мапперы, фабрики и т. д.

• На самом деле, MP в MVVMP является инициалами Марка Паркера, а полная форма — «Model View ViewModel by Mark Parker».

1. Принципы СОЛИД:

   • Принцип единой ответственности: У каждого класса должна быть только одна причина для изменений.

   • Принцип открытость-закрытость: Компоненты должны быть открыты для расширения, но закрыты для модификации.

   • Принцип замещения Лискова: Объекты суперкласса должны быть заменяемы объектами подклассов.

   • Принцип разделения интерфейсов: Ни один клиент не должен быть вынужден зависеть от интерфейсов, которые он не использует.

   • Принцип инверсии зависимостей: Зависимость от абстракций, а не от конкретики, чему способствует DI.

2. Инъекция зависимостей (DI): Реализация с использованием DI-контейнера для соблюдения принципа инверсии зависимостей.

Разработка бэкенда

Код бэкенда довольно прост. Эндпоинты (main.py):

"onboarding" предоставляет список вопросов анамнеза, которые необходимо заполнить при первом запуске приложения. Ответы будут сохранены на устройстве и использованы для персонализированной диагностики в будущем. "doctor" — основной эндпоинт: он генерирует вопросы на основе предыдущих ответов и карты пользователя, либо возвращает результат диагностики.

Модели:

Промпты:

Модуль промптов использует GPT-3.5 от OpenAI для генерации ответов на основе пользовательского ввода, анамнеза и заполненных анкет. Он возвращает пользователю соответствующие вопросы и советы по диагностике здоровья. Как видите, ничего сложного здесь нет. Код элементарен, а промпты - просто набор четких инструкций для LLM.

Настройте окружение и запустите сервер с помощью fastapi dev main.py.

Подробности:

• fastapi.tiangolo.com/tutorial/first-steps

• pypi.org/project/openai/

Открытие доступа к локальному хосту через Интернет

1. Зарегистрируйтесь на сайте ngrok.com и получите токен доступа.

2. Установите ngrok с сайта ngrok.com/download.

3. Выполните команду ngrok config add-authtoken <TOKEN>.

4. Запустите с помощью команды ngrok http http://localhost:8080 (при необходимости измените порт).

Подробные инструкции по настройке можно найти в документации ngrok.

Кодим приложение

Я не буду показывать здесь весь исходный код, для этого есть GitHub. Найти его можно по адресу: HouseMDAI iOS App. Вместо этого я остановлюсь только на важных (IMO) моментах.

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

Первым делом нам нужны модели, и они довольно просты (принцип KISS).

Теперь давайте сделаем онбординг. Продолжаем следовать KISS и SRP (Single Responsibility Principle), никакой бизнес-логики в представлениях, только UI. В данном случае - только список вопросов с прокруткой. Все данные и логика делегированы презентеру. Единственное, что здесь интересно, это небольшой вспомогательный метод bindingForQuestion, который, вероятно, должен быть в презентере, но сейчас это не имеет значения.

Вы будете удивлены, но в презентере также нет никакой бизнес-логики!

Все по-прежнему simple, stupid и имеет только одну ответственность. Presenter должен содержать только логику своего представления. Бизнес-логика уровня приложения находится вне его юрисдикции, поэтому презентер просто делегирует ее наверх по стэку вызова.

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

При использовании паттерна Dependency Injection зависимости предоставляются извне класса, а не инстанцируются внутри него. Это способствует развязке и позволяет упростить поддержку и тестирование кода.

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

Если вы рассматриваете возможность использования протоколов в представлениях SwiftUI, необходимо помнить об одном важном моменте. Поскольку View в SwiftUI - это структура, она требует явного указания типов своих свойств. Это означает, что вам придется сделать её дженериком и пробрасывать тип через весь стек вызовов, что приведет к появлению большого количества шаблонного кода.

Однако существует альтернативный подход, предлагаемый MarkParker5/AnyObservableObject.
Эта библиотека работает аналогично родным оберткам свойств SwiftUI, но убирает проверку типа во время компиляции в пользу проверки во время рантайма. Хотя такой подход может внести некоторые риски, их легко снизить, написав элементарные xcode тесты, которые просто инициализируют представления так же, как вы делаете это во время рантайма.

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

Итак, если презентер не содержит бизнес-логику, то где же она? Это задача для доменного слоя, который обычно содержит сервисы, провайдеры и менеджеры. У них всех очень схожее применение, и разница между ними до сих пор является предметом дискуссий. Давайте создадим OnboardingProvider, который будет содержать всю бизнес-логику процесса онбординга.

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

Теперь давайте соберем все вместе в корне приложения.

Это приложение SwiftUI устанавливает свое начальное состояние с помощью оберток полей StateObject. Оно инициализирует OnboardingProvider, OnboardingPresenter и HomePresenter в своем методе init. Провайдер OnboardingProvider отвечает за управление данными, связанными с онбордингом, а OnboardingPresenter управляет логикой представления онбординга. HomePresenter управляет главным домашним представлением.

В теле сцены приложения проверяется, нужна ли регистрация на сайте. Если да, то она представляет OnboardingView с OnboardingPresenter. В противном случае она представляет TabView, содержащий HomeView с HomePresenter и, если доступно, ProfileView.

Теперь настало время для домашнего экрана. Логика проста:

1. Получаем сообщение от пользователя

2. Используя сообщение, запрашиваем список вопросов из бэкенда

3. Показываем вопросы по одному, используя встроенную push-навигацию.

4. Добавляем ответы к запросу и повторяем 2-4, пока бэкенд-доктор не вернет окончательный результат

5. Показываем финальный результат

Похоже, я пропустил 4-й пункт... или нет? Поскольку представление не может содержать никакой логики, эту часть выполняет его презентер.

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

При отправке сообщения метод onSend() отправляет его на бэкенд с помощью DoctorProvider и ожидает ответа. В зависимости от типа ответа он обновляет навигационный путь, отображая либо набор вопросов, либо окончательный ответ.

Аналогично, когда заполняется вопросник, метод onQuestionaryFilled() отправляет заполненный вопросник на бэкенд и соответствующим образом обновляет путь навигации.

Здесь есть небольшое дублирование кода между методами onSend() и onQuestionaryFilled(), которое можно было бы отрефакторизовать в один метод для обработки обоих случаев. Однако оставим это как упражнение для дальнейшей доработки.

Модуль Questionary (View+Presenter) почти является копией Onboarding и просто делегирует логику до HomePresenter, поэтому я не вижу необходимости показывать код. Опять же, для этого есть github.

Последнее, что я хочу показать, это две реализации DoctorProvider, единственной обязанностью которых является вызов API и возврат DoctorResponse.

Первая использует наш бэкенд:

Вторая вызывает openai api напрямую (подход backendless) и является практически копией модуля подсказок из бэкенда:

Обе реализации легко взаимозаменяются благодаря инъекции зависимостей:

Другой пример

Посмотреть пример этой архитектуры в реальном приложении можно в моем проекте TwiTreads на github.com/MarkParker5/TwiTreads

Что делать дальше

• Интегрируйте аутентификацию и базу данных пользователей в бэкенд. Можете использовать официальный шаблон FastAPI из FastAPI Project Generation.

• Реализуйте логику аутентификации в приложении.

• Сосредоточьтесь на улучшении дизайна приложения, чтобы повысить удобство работы с ним. Давайте создавать красивые приложения!

Заключение

Приведенные проекты и ссылки на код служат реальными примерами, чтобы дать толчок вашей собственной разработке. Помните, что красота технологии заключается в итерациях. Начните с простого, создайте прототип и постоянно совершенствуйте его. Каждый шаг вперед приближает вас к овладению искусством разработки программного обеспечения и, возможно, к следующему большому прорыву в технологиях. Счастливого кодинга!

О других интересных проектах периодически пишу в телеграм.

№1. Libresolarbox

Проект OpenHardware SolarBox посвящен основам независимого фотоэлектрического источника питания и хранения энергии с использованием LiFePo4 аккумуляторов. Особое значение имеет графическое представление данных о солнечной энергии для контроля эффективности и в качестве основы для дальнейшего развития системы.

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

• Уровень: PowerBank - для мобильных устройств

• Уровень: eBike - для педальных велосипедов

• Уровень: BaseLoad - для автономного электроснабжения дома

LibreSolarBox Baseload, монолитная версия с инвертором и сетевым выключателем (не показан), для стационарного применения (домашние фотоэлектрические станции, емкостью от 0,9 до 2,4 кВт/ч)

Solarbox Powerbank

Powerbank используется для питания мобильных устройств, таких как ноутбуки, планшеты или iPhone, или освещения для активного отдыха. Необходимая емкость аккумулятора (при современном уровне развития техники) составляет до 72 Ач при напряжении системы 12 вольт (= 0,9 КВт-ч). Используются солнечные панели с номинальной мощностью от 100 до 300 Вт/

LibreSolarBox V.02. Для выставок и демонстраций боковая стенка из оргстекла позволяет видеть внутренности, но можно использовать и сплошную стенку.

LibreSolarBox V.02 Каркас основан на библиотеке компонентов UniProKit

Соединения LibreSolarBox V.02: сверху вниз: Powerswitch, CAN интерфейс, USB 5V, DC 12V, MC4 разъем для фотоэлектрической панели.

Аккумулятор LibreSolarBox V.02: ячейки CAM72 от CALB емкостью 72 А*ч, общая емкость около 0,92 кВт*ч

Solarbox Powerbank является частью более крупного проекта под названием [LibreSolarBox V.02], который осуществляется в сотрудничестве с LibreSolar и рабочей группой COS(H) и основан на LibreSolar_BMS.

Каркас бокса основан на Universal Prototyping Kit, открытом аппаратном конструкторе, что обеспечивает максимальную гибкость при разработке.

Эта версия заменяет более старую, разработанную нами, и архивируется здесь: SolarBox PowerBank (ранняя версия), и здесь: SolarBox Basics.

Дополнительную информацию можно найти на нашей странице проекта в Вики:

https://wiki.opensourceecology.de/SolarBox

Проект на GitHub:

https://github.com/CollectiveOpenSourceHardware/LibreSolarBox

№2. ZAC+

Цель этого проекта - разработать решение для долгосрочного хранения электрической энергии.

Как проект OSEG, ZAC+ представляет собой интересную альтернативу никель-железному аккумулятору («батарея Эдисона»), включенному в список OSE-US Top50.

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

Проект состоит из двух элементов:

1. цинково-воздушный топливный элемент Элемент состоит из углеродного катода, проводящего атмосферный кислород, и цинкового анода. В качестве электролита используется гидроксид калия, растворенный в воде (раствор едкого кали). Цинк «холодно сжигается» в качестве топлива, то есть окисляется, и образуется оксид цинка (ZnO). Теоретически максимальная плотность энергии ZAC составляет около 1,3 кВт*ч/кг.

2-й рециклер ZnO Для регенерации или перезарядки использованного топлива оксид цинка должен быть восстановлен до цинка с использованием энергии. Это можно сделать различными способами, например, при высоких температурах (>1200°C) с добавлением углерода или более простым способом - в процессе гальванизации, который и является тем решением, на которое мы ориентируемся в данном случае.

ZAC+ обладает рядом преимуществ, особенно по сравнению с другими типами аккумуляторных систем (свинцово-кислотными, литиевыми и т. д.), в том числе следующими:

Неограниченное количество циклов

• Неограниченный срок хранения

• Нечувствительность к глубокому разряду и перезарядке

• Простые и дешевые компоненты, доступные повсеместно

• Компоненты абсолютно безвредны для окружающей среды

• Самая высокая плотность энергии

Применение

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

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

Цели

• Сезонное хранение большого количества энергии в течение нескольких месяцев

• Определение эффективности всей системы (ZAC и утилизатор ZnO).

• Функционирующий прототип

• Собственное производство газодиффузионного электрода или его альтернативы

Экспозиция

• Сотрудничество с внешним партнером, Revoneer

• Создание прототипов с помощью аддитивного производства/3D-печати

Ссылки:

• https://wiki.opensourceecology.de/Zn/O-Brennstoffzelle

• https://github.com/case06/ZACplus

№3 FROSE2

Проект Frose2 предусматривает строительство фрезерного станка OSEG с рабочей зоной примерно 100 x 70 x 8 см. Это важная часть и способствует дальнейшему развитию других проектов OSEG, например:

• разработка общих прототипов

• Оборудование для мастерских OpenEcoLabs: самовоспроизведение

• Производственный станок для компонентов OpenHardware (например, UniProKit)

• Проект LibreSolarBox: отверстия в пластинах корпуса для соединений/разъемов

• Проект OHLOOM: производство деталей боковых панелей для наборов, в качестве основы для курсов (повышение квалификации) и мастер-классов.

• Проект ZAC+: фрезерные реакционные камеры с входными и выходными каналами из оргстекла.

Основой для конструкции послужил каркас старого специального станка с ЧПУ на базе Isel, который можно было купить очень дешево, и который изначально состоял только из основного корпуса и осей X и Y.

Это означало, что ось Z была недоступна, и ее пришлось полностью перепроектировать и переделать.

Нам удалось использовать очень качественный конструкторский план OpenHardware от Себастьяна Конца, оператора популярного и очень рекомендуемого канала на YouTube, посвященного фрезерным станкам с ЧПУ, которого мы хотели бы еще раз поблагодарить за это.

Мы внесли несколько небольших изменений в наши условия (например, просверлили отверстия для крепления оси Z к порталу) и перенесли все CAD-файлы в предпочитаемый нами формат FreeCAD.

Кроме того, на всех осях были установлены новые шаговые двигатели и разработан подходящий контроллер, основанный на Arduino Nano с открытым исходным кодом и прошивкой GRBL 1.1. В качестве управляющего программного обеспечения мы используем bCNC, также имеющий открытый исходный код.

В качестве фрезерного шпинделя используется Kress 1050 FME с частотой вращения 24000 об/мин.

Поперечная пластина

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

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

Сборка

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

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

Составные части

Алюминиевые панели разработаны таким образом, чтобы их можно было изготовить вручную (с помощью дрели). При выборе размеров панелей была сделана попытка использовать панели, которые уже имеют правильные стандартные размеры и поэтому не требуют дополнительной обработки. Только панель для дублеров нужно прорезать один раз по центру.

Для получения дополнительной информации и подробной спецификации материалов (BOM), вот ссылка на страницу проекта на нашей платформе Wiki:

https://wiki.opensourceecology.de/Portalfr%C3%A4se

Посмотреть 3D-модель в браузере:

https://myhub.autodesk360.com/ue2971a9d/g/shares/SH7f1edQT22b515c761ee0871d644037a8fd

Станок за 500€:

https://www.instructables.com/LOW-COST-DIY-500-CNC-MILL/

№4 Намоточная машина для армированных труб

https://wiki.opensourceecology.de/Wickelmaschine_faserverst%C3%A4rkte_Rohre

Разработка, проектирование и изготовление прототипа были выполнены в рамках магистерской диссертации в Университете прикладных наук Оснабрюка.

stl-файлы и чертежи можно скачать по следующей ссылке: https://github.com/Simon0613/Wickelmaschine.

Эта намоточная машина может использоваться для производства армированных волокном труб, например (CFRP или GFRP). Размеры трубок могут быть индивидуальными и могут использоваться, например, для изготовления спортивного или туристического снаряжения. Машина работает по технологии укладки или обмотки лентой, при которой однонаправленные армированные пластиковые ленты обматываются вокруг сердечника и скрепляются с нижними слоями под воздействием источника тепла.

Намоточный станок может быть изготовлен с использованием простых производственных процессов. Большинство компонентов можно изготовить с помощью 3D-принтера FDM. Также используются стандартные детали, такие как винты, подшипники, гайки с оплавлением и пружины. Для привода осей используются компоненты, которые можно найти во многих 3D-принтерах: Шаговые двигатели, ремни и шкивы GT2, Arduino Uno, CNC shield и т.д. Остальная часть состоит из полуфабрикатов, таких как трубки и плоские профили, которые нужно распилить, просверлить и немного обработать напильником.

Размеры труб могут быть спроектированы в соответствии с личными требованиями. Станок может производить трубы диаметром 15-55 мм. Длину труб можно регулировать по желанию, только заранее необходимо скорректировать размеры станка под нужную длину труб.

Для сборки системы понадобятся следующие инструменты:

• Дрель

• Инструмент для разметки отверстий

• Плоский напильник

• Сверло 3,3 мм

• Сверло 4,5 мм

• Метчик M4

• Зенкер

• Зенковка для винтов с цилиндрической головкой M4

• Паяльник

• Измерительная лента

• Пила

• Очиститель

• Набор торцевых шестигранных ключей

Предыдущий пост:

Open-Source #1 Железо

Всем добра =)