Головна / Статті

П’ять проєктів на Rust для навчання з контрольними точками та захисними механізмами на основі ШІ

Як вибрати проект на Rust, який змусить вас опанувати концепції власності, асинхронності та конкурентності, із п’ятьма чітко визначеними ідеями, етапними цілями та правилами використання ШІ під час навчання.

Видавець: REACTAPP.TOP13 хв читання2883 слів

Джерела: 5 Rust Projects That Can Teach You More Than a Course

Rust завантажує заздалегідь багато концепцій: власність, позичення, терміни життя, трейти, обробку помилок, конкурентність, асинхронність, а також екосистему крейтів, якою потрібно орієнтуватися перед тим, як щось корисне почне працювати. Багато учнів намагаються вирішити це, збираючи туторіали, але все одно застрягають перед порожнім файлом main.rs. Більш надійним підходом є вибір проєкту настільки складного, щоб кожна з цих концепцій стала проблемою, яку потрібно вирішити, а не розділом для читання. У цьому посібнику описано п’ять таких проєктів, що вони вас навчать, як створити першу версію, яку можна завершити, та як використовувати допомогу ШІ, щоб вона прискорила ваш процес навчання, не замінюючи вас у самому процесі навчання.

Чому складний проєкт кращий за інший курс

Курс презентує концепції у порядку, обраному іншою особою, при цьому складність вже усунута. Справжній проект робить навпаки: ви стикаєтесь з перешкодою, і сама ця перешкода підказує, яку концепцію потрібно опанувати далі. Протягом цього процесу ви читаєте справжню документацію, робите архітектурні вибори, які згодом можуть стати причиною жалю, розшифровуєте заплутані помилки компілятора, виявляєте проблеми з продуктивністю та вчитеся, як різні компоненти взаємодіють між собою. Саме ці навички стають у пригоді у професійній роботі, і їх важко здобути пасивно.

Ці п’ять проектів обрано тому, що кожен з них використовує кілька аспектів мови одночасно. Якщо ви хочете більш широкий каталог ідей, наш попередній матеріал про навчання Rust за допомогою десяти проектів охоплює ще більше варіантів; тут увага зосереджена на визначенні меж кожного проекту, щоб він залишався навчальним, а не перевантажував користувача.

Проект 1: ваш власний термінальний агент для програмування

Асистенти з кодування на основі штучного інтелекту у командному рядку є одним із найактивніших напрямків інструментарію для розробників. Такі інструменти, як Claude Code, Codex та різноманітні альтернативи з відкритим кодом, дозволяють розробнику сформулювати мету, а агент перевіряє файли, викликає інструменти, редагує код та повідомляє про результати, замість того щоб розробник вручну виконував кожну команду. Спрощена версія цього циклу є чудовим завданням для вивчення мови Rust, оскільки вона одночасно стосується мережевих зв’язків, процесів, файлової системи та користувацького інтерфейсу.

Основний цикл є простим: користувач вводить дані у термінальний інтерфейс, ваша програма передає цю розмову до мовної моделі, модель може відповісти з проханням скористатися певним інструментом, ваш код на мові Rust виконує цей інструмент, а результат повертається до моделі для подальших дій.

You → Terminal UI → LLM → Tool Request → Your Rust Program → Result → LLM

Цікавою є частина, де інформація надсилається від моделі назад у вашу програму. Модель ніколи не впливає безпосередньо на ваш комп’ютер; вона може лише запитувати, а ваш код вирішує, чи та як діяти. Саме в цьому межу знаходиться більша частина роботи з проектування.

Перша версія, яку можна завершити

Почніть із кількох інструментів та нічого більше:

  • відкрити та прочитати файл
  • створити або перезаписати файл
  • пошук у каталозі
  • виконати команду оболонки
  • надати базову інформацію про проект
  • надіслати результат кожного інструменту назад до моделі

Як тільки цей цикл буде працювати повністю, розширюйте його поетапно: зберігайте історію розмови між кроками, передавайте відповіді у реальному часі, додавайте перевірки дозволів перед виконанням руйнівних дій, описуйте інструменти за допомогою чітких схем, підтримуйте скасування поточного кроку та покращуйте відображення результатів у терміналі. Перевіркам дозволів слід приділити особливу увагу. Агент, який може виконувати довільні команди на вашому комп’ютері, повинен запитувати дозволу перед тим, як записувати дані поза папкою проекту чи виконувати щось, що він раніше не виконував.

Що це вчить

  • асинхронний Rust та HTTP-клієнти для взаємодії з API моделі
  • серіалізацію та десеріалізацію JSON для запитів, відповідей та викликів інструментів
  • обробку відповідей у реальному часі
  • створення та керування дочірніми процесами
  • API файлової системи
  • моделювання циклу агента як машини станів
  • Обробка помилок у мережі, під час парсингу та при збоях процесів
  • Дизайн інтерфейсу командного рядка та терміналу
  • Використання інструментів як протоколу
  • Ще однією перевагою є те, що проект насправді ніколи не закінчується. Ви можете продовжувати його вдосконалювати протягом місяців, що робить його гарною довгостроковою платформою для тестування. Якщо ви хочете побачити, як виглядає той самий цикл з точки зору продукту та безпеки, наша стаття про створення особистого AI-агента з отриманим доступом детальніше розглядає аспекти довіри.

    Вирішіть, що саме ви оптимізуєте

    Перш ніж писати будь-який код, будьте чесні щодо своєї мети. Вивчення Rust, створення проекту для портфоліо, розробка інструменту, яким ви будете користуватися щодня, експерименти з ШІ та підготовка до ролі у сфері системного програмування — усе це призводить до різних рішень. Проект для портфоліо вимагає досконалості; щоденний інструмент — надійності; навчальний проект — зусиль.

    Якщо пріоритетом є навчання, не дозволяйте асистенту створювати весь кодовий базис. Видалення неприємних частин також позбавляє вас багатьох знань, які ці частини могли б дати. Запитувати у асистента пояснення щодо помилки перевірки позик чи уточнення незрозумілої частини документації — це нормально. Доручати проектування до того, як ви зрозуміли систему, — ні. Проект, який потребує трьох днів для розуміння, зазвичай навчає значно більше, ніж проект, створений за три години.

    Проект 2: десктопний додаток з Tauri

    Rust має репутацію мови для серверів, інструментів командного рядка та коду низького рівня, але вона також є хорошим вибором для десктопного програмного забезпечення. Tauri поєднує веб-інтерфейс із бекендом на Rust, тож ви можете створити додаток, який виглядає та функціонує як сучасне десктопне програмне забезпечення, при цьому ключова логіка виконується на Rust. Якщо ви ще розглядаєте Tauri порівняно з іншими варіантами, наша порівняльна стаття JavaScript-десктопних фреймворків описує переваги та недоліки кожного з них.

    Пропустіть стандартні списки справ та створіть щось, що ви дійсно будете відкривати щодня. Однією конкретною ідеєю є місцевий асистент для підвищення продуктивності, який записує аудіо, перекладає мовлення у текст, зберігає нотатки на вашому власному диску та читає обраний текст назад вам. Іншими хорошими варіантами є особистий органайзер файлів, робоче середовище Markdown, панель керування для розробників, інструмент для обробки медіа чи місцевий інструмент на основі ШІ.

    Ідея має менше значення, ніж зв’язок між веб-інтерфейсом та нативним бекендом. Кожна кнопка в інтерфейсі зрештою стає запитом через цей кордон, тож правильне проектування інтерфейсу — це справжній урок. Розумною першою метою є створення однієї команди, яка реалізована на мові Rust та викликається з фронтенду, і яка виконує щось, чого браузер не може зробити самостійно, наприклад, читання списку файлів у папці.

    Що це вчить

    • структурування додатку на Rust із кількома шарами
  • комунікація між фронтендом та Rust
  • пакування та розповсюдження десктопних додатків
  • локальне зберігання даних
  • потоки та фонові завдання, які забезпечують реактивність інтерфейсу
  • операції з файловою системою
  • виклик зовнішніх API та сервісів
  • керування станом
  • обробка помилок із відображенням корисних повідомлень у інтерфейсі
  • аспекти безпеки для нативного додатку, який відображає веб-контент
  • Загальний урок полягає у тому, що програмування стає набагато складнішим, коли додаток починає працювати з реальною операційною системою. Читання файлу — це один рядок коду. Однак безпечна обробка файлів, чітке повідомлення про помилки, збереження реактивності під час повільних операцій та однакова робота на різних пристроях — це зовсім інша проблема, і саме цей розрив є тим досвідом, який варто здобути.

    Проєкт 3: гра типу «оборона веж» у Bevy

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

    Bevy ідеально підходить для тих, хто вивчає Rust, адже він побудований на системі Entity Component System (ECS). Замість великих об’єктів, які об’єднують усю поведінку, ентитет — це переважно ідентифікатор з приєднаними до нього компонентами, а системи — це функції, які виконуються для кожного ентитета з певним набором компонентів. Проєктиль може мати координати положення, швидкість та значення пошкодження; система руху оновлює всі ці параметри, а система зіткнень керує процесом нанесення пошкоджень. Цей перехід від об’єктів до даних та функцій є однією з найцінніших концепцій, які Rust та Bevy можуть запропонувати.

    Чому саме жанр захисту веж

    У цьому жанрі кількість ентитетів швидко зростає, і саме це робить його особливо корисним для навчання. Одна карта може включати:

    • сотні ворогів одночасно
    • кілька веж із різною поведінкою
  • снаряди під час польоту
  • системи здоров’я та пошкоджень
  • шукання шляху
  • хвилі атакуючих
  • покращення
  • кілька типів ворогів
  • На такому рівні складності правильність вже не є єдиним питанням. Починаєш задаватися питанням, скільки ресурсів гра використовує на кожному кадрі. Це питання природно веде до аналізу продуктивності, структурування даних, планування роботи систем, використання пам’яті та вибору алгоритмів, які не зазнають збоїв при зростанні обсягу даних. Хорошим першим кроком є створення ситуації, коли один ворог рухається по фіксованому шляху, а одна вежа стріляє в нього; все інше можна додавати поступово, як тільки цей цикл стане стабільним.

    Що це вчить

    • як структурована система Entity Component System
    • гейм-луп та таймінг кадрів
    • реагування на події
    • керування станом між меню, рівнями та після закінчення гри
    • аналіз продуктивності
    • дизайн, орієнтований на дані
    • управління ресурсами
    • основи відтворення змісту
    • обробка вхідних даних
    • оптимізація

    Ігри також навчають того, чого рідко досягають навчальні посібники: як взаємодіють кілька незалежних систем, коли програма стає справді складною, та як невеликі зміни в одній системі впливають на інші.

    Проєкт 4: вбудоване пристрій із машинним навчанням безпосередньо на пристрої

    Саме з обмеженим обладнанням Rust стає ще цікавішим: обмежена кількість пам’яті, малий бюджет енергії та обмежений час роботи процесора. Замість ноутбука варто орієнтуватися на мікроконтролер чи невеликий пристрій типу edge device.

    Практичним прикладом є пристрій, який стежить за своїм оточенням та реагує на зміни. Він може збирати дані про:

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

    Крім того, ви можете додати компактну модель машинного навчання для виконання однієї конкретної задачі: виявлення аномалій, розпізнавання жестів чи прослуховування спеціального слова для активації. Зробіть модель простою; справжнє навчання полягає у впорядкуванні всього на обмеженому обладнанні.

    Щоб почати, вам не потрібне дороге обладнання. Емулятор чи симулятор достатні для ознайомлення з архітектурою та методами програмування, а до фізичної плати можна перейти, коли програмне забезпечення почне працювати.

    Чому Rust у вбудованих системах здається іншим

    Десктопна програма має повну стандартну бібліотеку, достатню кількість пам’яті, швидкий процесор та операційну систему, яка керує безліччю низькорівневих деталей. У розробці вбудованих систем більша частина цього відсутня, що призводить до появи нового набору проблем:

    • no_std у Rust, коли стандартна бібліотека недоступна
    • робота в умовах суворих обмежень пам’яті
    • інтерфейси з обладнанням
  • переривання
  • поведінка в реальному часі
  • драйвери пристроїв
  • комунікація з периферійними пристроями
  • міжкомпіляція
  • інструменти та екосистема, пов’язані з конкретними мікроконтролерами
  • Це один із найясніших прикладів того, чому Rust має значення не лише у звичайних додатках. Потрібно розуміти, що насправді робить пристрій, адже немає нічого, що можна було б приховати. Робота з вбудованими системами також пов’язує Rust із робототехнікою, автомобільними системами, промисловим обладнанням та іншими галузями, що вимагають потужного обладнання.

    Проєкт 5: адаптивний балансувальник навантаження

    Для розробників бекенду інші CRUD API рідко суттєво розширюють їхні навички. Створення інфраструктури — це те, що справді розвиває знання. Балансувальник навантаження є гарним прикладом: він знаходиться між клієнтами та набором серверів бекенду, і для кожного вхідного запиту вирішує, який працівник має його обробити, замість того щоб направляти весь трафік на одну машину.

    Основна структура проста: клієнти під’єднуються до вашого процесу на Rust, і він передає кожен запит одному з кількох працівників.

    ┌─────────────┐
                    │   Clients   │
                    └──────┬──────┘
                           │
                           ▼
                  ┌─────────────────┐
                  │  Rust Load      │
                  │    Balancer     │
                  └───────┬─────────┘
                      ┌───┴───┐
                      ▼       ▼
                 ┌────────┐ ┌────────┐
                 │Worker 1│ │Worker 2│
                 └────────┘ └────────┘
    

    Етапи розвитку від примітивного до адаптивного підходу

    Почніть зі звичайного роутингу за принципом «кругової черги», коли кожен запит по черзі надходить до наступного працівника. Це легко зрозуміло та дає базову основу. Потім поступово додавайте інтелектуальні функції:

    • вимірюйте час відповіді та кількість помилок у кожного працівника
    • виявляйте несправні працівники та припиняйте направляти до них запити
    • застосовуйте обмеження на кількість з’єднань
  • спробуйте альтернативні стратегії маршрутизації та порівняйте їх під навантаженням
  • Зрештою балансувальник може скоригувати свою поведінку відповідно до умов реального трафіку замість дотримання фіксованих правил.

    Де виникають труднощі

    Уявіть, що один з працівників раптово уповільнює роботу. Чи варто продовжувати надсилати туди нові запити? Майже напевно, ні. Ще складніше — уявіть ситуацію, коли кілька працівників одночасно погіршують свою продуктивність з різних причин: один перевантажений, у одного проблеми з мережевим з’єднанням, ще один виконує операції збирання сміття. Ваша система мусить спостерігати за тим, що відбувається, та швидко приймати рішення, не стаючи самою перешкодою. Для цього потрібно враховувати:

    • конкурентність
    • основи мережевих технологій
    • TCP та HTTP
    • зворотне проксіювання
    • перевірки стану та таймаути
    • об’єднання з’єднань до працівників
    • збір метрик
    • справедливе розподілення навантаження
    • зворотний тиск, коли всі працівники зайняті
    • грайливе управління несправностями
    • мислення у рамках розподілених систем

    Ви можете експериментувати з політикою маршрутизації за допомогою ШІ, але розглядайте це суто як експеримент. Критична інфраструктура ніколи не повинна сліпо покладатися на рішення моделей, і завжди має бути доступний детерміністичний запасний варіант. ШІ саме по собі нічого не додає; мета — виміряти, чи справді воно покращує систему порівняно з простою, добре зрозумілою стратегією.

    Що є спільним у цих проектах

    Спільним елементом є не синтаксис. Це складність, якої неможливо уникнути.

    Навчальний посібник може показати, як працює Arc<Mutex<T>>; проект змушує вас зрозуміти, чому взаємно використовувані дані взагалі потребують синхронізації, зазвичай після того, як компілятор відмовляється дозволити їх небезпечне спільне використання. Асинхронні функції легко пояснити на папері; справжня програма демонструє, що відбувається, коли кілька завдань взаємодіють, коли запит скасовується на півдорозі чи коли зникає мережеве з’єднання. Книга може пояснити концепцію власності; проект змушує вас розробляти структури, у яких кожен ресурс має правильного власника та звільняється у правильний час. Саме ця різниця є відмінністю між знанням мови та вмінням створювати програмне забезпечення за її допомогою.

    Виберіть проект, який трохи ускладнює справу

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

    Це відчуття — хороший знак. Готуйтеся до того, що доведеться читати багато документації, ламати свій код, неправильно розуміти API, писати абстракції, які виявляються неефективними, а потім їх замінювати, а також неодноразово сперечатися з компілятором. Через кілька днів те, що здавалося неможливим, почне мати сенс. Цей досвід дуже важко відтворити, просто переглянувши ще один туторіал.

    Використання ШІ без замовлення навчання

    Спосіб, яким ви використовуєте допомогу ШІ, може більше, ніж будь-який інший фактор, вплинути на те, скільки нового ви дізнаєтесь під час роботи над проектом. Сучасні асистенти справді корисні: вони пояснюють повідомлення про помилки, стискають довгу документацію, пропонують підходи та допомагають розбиратися з багами. Ключове — не перетворювати ШІ на заміну розуміння, а використовувати його як інструмент.

    Для проекту, орієнтованого на навчання, ефективна дисципліна виглядає так:

    • самостійно написати першу версію
    • прочитати відповідну документацію перед тим, як просити допомоги
    • спробувати вирішити кожну проблему самостійно, перш ніж просити рішення
    • коли застрягли, просіть пояснення, а не готовий код
    • самостійно впровадити виправлення, навіть якщо тепер знаєте, як воно має виглядати
    • переконайтеся, що можете пояснити кожну важливу частину системи без підтримки документації

    Усе це не означає уникнення ШІ. Це означає переконатися, що саме ви продовжуєте міркувати.

    Підбір проекту під ваші цілі

    Нехай тип інженера, яким ви хочете стати, керує вашим вибором:

    • ШІ та інструменти для розробників: створіть агента для кодування в терміналі
    • Десктопне програмне забезпечення: створіть додаток на Tauri
    • Ігри та продуктивність: створіть ігру типу «тауер-діфенс» на Bevy
    • Робототехніка, апаратне забезпечення чи робота на низькому рівні: створіть вбудоване пристрій
    • Інфраструктура бекенду та розподілені системи: адаптивний балансувальник навантаження

    Який би варіант ви не обрали, не прагніть до досконалості. Спочатку запустіть найпростішу працездатну версію, а потім вдосконалюйте її.

    Основні висновки

    • Обирайте проекти, складність яких змушує вас працювати з конкурентністю, асинхронністю та обробкою помилок, замість того щоб читати про це у абстрактних формулюваннях.
    • Визначте невелику початкову мету для кожного проекту та поступово розширюйте її; простий функціональний цикл навчить більше, ніж амбітний дизайн, який так і не буде запущений.
    • Заздалегідь вирішіть, чи ви навчаєтесь, створюєте елемент портфоліо чи розробляєте інструмент, адже кожна мета вимагає інших підходів.
    • Використовуйте ШІ для пояснень, а не для створення коду, оскільки метою є навчання, та залишайте детерміністичні альтернативи там, де модель приймає рішення в реальній системі.
    • Цикл створення, руйнування, дослідження, перепроєктування та оптимізації є джерелом більшості знань про Rust, і кілька днів роботи в цьому циклі можуть замінити багато годин пасивних туторіалів.