В одному тільки Steam 💨 у мене 500+ ігор. Звісно, далеко не все я прям свідомо купував — більшість з них у мене з якихось бандлів або взагалі дісталися безплатно. І що більше ігор, то менше виникає бажання купити щось ще, бо й так все «потрібне» вже є.

Разом з іграми дружини й нашого спільного дружбана в нас близько 900 ігор у Steam Family. Тож у якийсь момент я зрозумів, що замість спонтанних покупок усього підряд на розпродажах значно вигідніше купувати тільки те, у що готовий грати прямо зараз — за ту ціну, яка стоїть зараз. Можете спробувати порівняти, скільки ви за гру віддали грошей і як довго потім в неї грали. Взяти щось за повну вартість і пройти повністю виявляється вигідніше, ніж купити пʼять ігор, в яких ви не просунетеся далі головного меню.

Якщо не принципово, де саме грати, то хотілося б уникати випадків, коли купуєш те, що в тебе вже й так є. Як цього досягти?

Зі стімом приблизно зрозуміло. Якщо гра є в спільній бібліотеці, то купувати її ще раз найчастіше немає сенсу. Але що робити з GOG, Epic Games, Xbox Games, Amazon Games, Nintendo Switch тощо? За весь час існування того ж епіка, я купив там усього три гри, але в бібліотеці їх вже понад 400 — решту отримав безплатно.

Багато хто радить GOG Galaxy, який вміє підтягувати списки звідусіль. Тільки проблема в тому, що я не користуюся GOG Galaxy — і не почну. Просто нема такої звички. Якщо треба глянути якусь гру, я завжди піду саме в Steam. Хотілося б бачити всі свої ігри саме там.

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

Тепер про те, як я автоматизував додавання всіх своїх ігор як кураторські рецензії: а ніяк! Я це все вручну зробив.

Поміркувавши, скільки часу треба, щоб розбиратися з усіма апішками (які ще й не для всього є) або автоматизувати це через взаємодію з вебсторінками, я дійшов висновку, що легше наклацати це все власноруч. Так, на це пішло декілька годин, але задача одноразова — далі треба тільки підтримувати в актуальному стані, додаючи нові ігри.

Тепер заходячи на сторінку з грою, я бачу, чи вона вже десь в мене є. І якось так виходить, що купувати щось нове навіть бажання вже не виникає. За 2024 рік я купив усього 12 ігор, а за 2025 — дві.

До речі, якщо тема кураторів — це щось нове для вас, то дуже раджу підписатися на Обережно, русняві ігри, які публікують застереження про ігри, зроблені москалями, а також на КУЛІ, які пишуть про наявність української локалізації в грі (офіційної чи через українізатор). В останніх і власний сайт є.

Я користувався й у деяких проєктах досі користуюся білд-системою #Qbs (неодноразово писав вище). Але як же вона мене замахала! Це просто квінтесенція того, як робити не треба.

Почав користуватися нею через очевидні переваги:
1) декларативна мова, що базується на #QML, з можливостями додавати імперативні вставки на 💻;
2) добре структуровані концепції;
3) швидкий білд без проміжних кроків;
4) не 🤮 CMake 🙂

Реальність трохи більш прозаїчна: мова там не QML, а «діалект QML» — семантика значно відрізняється, бо чинні мейнтейнери на QML ніколи й не писали, лол. Імперативні вставки на JS працюють не так, як очікуєш. Дебажити це неможливо. Нема простих способів робити банальні речі, як-от подивитися команди, які при білді запускаються. Думаєте, достатньо написати -v? А ось хєр! у такому режимі Qbs висирає гігатонну логів, які мають бодай-якийсь сенс виключно для розробників самого кьюбса. (Насправді ж треба писати --command-echo-mode command-line 🤕).

Ну а добре структуровані й логічні концепції… постійно стають на заваді! Наприклад, треба мені було задеплоїти разом зі своєю програмою теку з розширеннями QML з самої 💻. Але кьюбс нічого не знає про теки — він оперує тільки файлами, які він називає артефактами. Артефакти позначаються теґами: один артефакт може мати багато різних теґів, а одному теґу можуть належати різноманітні артефакти. Конкретні теґи опрацьовуються певними правилами. Правила містяться у модулях, на які треба додати залежність. Правило завжди має чіткі вхідні й вихідні артефакти. З усього цього Qbs будує граф правил. Але кьюбс ніколи не робить зайвої роботи — це його фішка. Він будує тільки те, що мусить. І все завжди починається з вашого найголовнішого продукту, який також має теґ.

Тобто білд-система дивиться, і така: «Ага, оцей продукт — це артефакт з теґом application. Звідки його взяти?» — і починає шукати правила, які дають на вихід application. Таким правилом є, наприклад, те, що викликає компонувальник. Воно своєю чергою вимагає на вхід якісь артефакти на кшталт obj, staticlibrary і таке інше. Де взяти їх? Ну, obj можна отримати з cpp. Ви зрозуміли, короч. Хоча це все вельми спрощено.

Прикол у тому, що якщо раптом для побудови фінального продукту кьюбсу не треба зачіпати якісь конкретні теґи, то він і не буде. Я так писав модуль для автоматичного збирання залежностей для моїх QML-файлів, додав його у білд — а воно нічого не робить. І зазвичай геть не очевидно, чого саме.

Інша тема, що всі артефакти — це унікальні сутності, навіть якщо фізично вони вказують на одні й ті ж файли. Так, я раніше написав, ніби це тотожні штуки, але не зовсім. Зібрав я, значить, залежності для QML-файлів — це певні ліби з самого кьюта. Є в мене Foo.qml, якому потрібні qlib1 і qlib2, а є Bar.qml, якому потрібні qlib2 й qlib3 — фізично всі ці ліби лежать у теці з кьютом, але для кожного продукту я створюю «віртуальні» артефакти, щоб все це правильно бачила білд-система. Потім я всі ці залежності хочу встановити в цільову теку програми. А ніііііфііііігаааа! 😡 Qbs такий: «ти встановлюєш qlib2, але там вже лежить інший!» — сґітісаI еґґоґ.

Додати до цього всього ду-у-у-уже специфічний спосіб описувати модулі й правила, причому на ES5, практичну неможливість побачити свій проєкт «очима Qbs», бажано візуально, відсутність просторів імен, що ставить хрест на перевикористанні деяких штук у різних проєктах, тяжку взаємодію з єдиним доступним там менеджером пакетів — Conan (як альтернативу радять pkg-config… у 2k25…), а також майже нульові можливості для зневадження проблемних білд-скриптів — і не лишається майже нічого, за що можна було б зачепитися (окрім того факту, що це досі не CMake 😂).

А, і ще сорци хоч і лежать на ґітгабі — але там чисто дзеркало. PR кинути не можна — треба натомість створювати патчсет на кьютовий ґерріт.

Отже, подивилися ми з друганами на все це вкотре й вирішили, що час щось міняти. Але на що саме? Один з нас розпочав аналіз альтернатив, згодом долучився я, і… здається, нам вдалося знайти непогані варіанти. Днями розповім.

Якщо вже мова йде про вибір системи складання, то непогано б мати якісь критерії, за якими оцінювати кандидатів.

І на мою думку побудова складних 💻-програм — чудовий контрольний тест. Дивіться самі:
- Qt базується на 💻, а всі знають, що у нас в C++ компілювати складні проєкти зазвичай доволі важко;
- при цьому більшість Qt-програм — кросплатформні (принаймні ті, що пишу я);
- але також Qt — це надбудова над C++, бо там є низка тулів для генерації коду: MOC, RCC тощо — без яких усе це не працюватиме;
- якщо використовувати QML, а я завжди використовую, то ще додається ціла низка тулів, щоб генерувати правильні QML-модулі;
- безплатна версія Qt розповсюджується під LGPL, а значить найпростіший спосіб пакувати програми — через динамічне компонування. А це значить, що треба правильно розкласти побудовані бібліотеки по теках;
- та й загалом структура готової програми на трьох головних десктопних системах відрізняється: на 🪟 ліби лежать під екзешніком, на 🍏 використовуються бандли, на 🐧 просто хаос (tar.gz, AppImage, Flatpak, ну ви знаєте).

Хтось каже мені: нащо ті системи взагалі потрібні — достатньо одного Makefile. Ну, якщо вам достатньо, то можу лише позаздрити. У переважній більшості моїх проєктів усе трохи складніше:

1. Підтримка macOS + Windows + Linux з коробки, а точніше різних компіляторів на цих системах (я не хочу памʼятати й вручну встановлювати параметри під кожний з них).
2. Я люблю пробувати «свіженьке», тому білд-система має підтримувати фічі нових стандартів C++, зокрема модулі, які вийшли ще в C++20.
3. Принаймні базова підтримка Qt: система мусить розуміти структуру цього фреймворку, а також вміти викликати всі ті додаткові тули типу meta-object compiler.
4. Бажано, щоб про QML система також знала.
5. А якщо ні, то свої власні «правила» писати має бути дуже легко! Якщо я хочу запакувати графічні асети в ресурси автоматично або обробити їх перед цим якоюсь тулзою, то не хотілося б витрачати на це тиждень.
6. Я не хочу писати «зовнішні» скрипти для цього, бо це додаткова залежність для хостової системи. Мова системи складання має задовольняти всі базові потреби типу читання/записування файлів, як бінарних, так і текстових, парсинг, виклик зовнішніх утиліт тощо.
7. До речі щодо залежностей: треба якусь зручну роботу з 3rd-parties. Тобто підтримка пекедж-менеджерів на кшталт Conan або vcpkg, або хоча б можливість стягувати щось з інтернетів (без написання власних скриптів знов-таки).
8. Пакування готової програми у звичний для системи формат: інстолери для вінди, DMG на macOS, будь-що на лінукс (там люди все одно звикли страждати). До речі, у сучасності це все треба ще й правильно підписати якимись там сертифікатами. Хто це має робити? Система побудови звісно!
9. Є штуки як той же CMake, які самі нічого не роблять, а тільки генерують інструкції для інших систем штибу make або ninja. Юніксолюби посперечаються, але на мій погляд це дурня якась! Система має білдити все сама, бо я не хочу зайвих залежностей.
10. А взагалі не тільки білдити, а ще й запускати. Мені у 2k25 ліньки шукати в теці build потрібний мені бінарь. Хочу, щоб можна було написати mega run, якщо уявна система називається mega.
11. Я пишу у VS Code, а деякі мої колеги в якихось IDE, тому непогано б мати інтеграції чи принаймні здатність генерувати compile_commands.json.
12. З роками я дійшов до плюс-мінус узагальненої структури всіх своїх проєктів. Це дуже допомагає бутстрапити нові швидко. Було б круто мати механізм перевикористання хоча б кастомних правил між цими проєктами.
13. Ну й найголовніше: побудова всього проєкту має виконуватися викликом однієї команди! Включно з отриманням усіх залежностей, а ліпше ще й зі встановленням всіх необхідних тулсетів. Не важливо, чи це CI, чи компʼютер розробника, чи ще щось — одна команда на все!

Хіба я забагато прошу?

Не складно зауважити, що багато з цих вимог покриваються сучасними інструментами в інших мовах. Але в мене C++, а це одразу головняк ×10.

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

Я, певно, був останнім, хто порадив пану Шевцову 👆 подивитися на #Nushell 🆕, і тому тепер не можу лишитися осторонь 🙂 (Можете почитати оригінальний допис, бо це якоюсь мірою відповідь на нього). Але спершу окреслю декілька важливих моментів, які є фундаментом подальших міркувань.

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

По-друге, я не з тих, хто топить суто за GUI. На жаль зробити хороший графічний інтерфейс вельми складно, особливо достатньо гнучкий, тому ми їх бачимо так мало. Є речі, які значно швидше робити в командних оболонках, і так вже вийшло, що всі популярні — саме текстові.

Отже, я НЕ користуюся 💻 або tmux, не фапаю на TUI і не пишу AWK з голови. Мені не треба керувати кластером зі 100500 серверів; у мене нема компів, де з усіх інструментів доступні тільки ls, echo і vi. У мене нема гігабайта шел-скриптів, які я збирав би або писав десятиліттями.

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

Якщо ви такі ж, як я (і якщо вам не встигли напарити, що «кожен програміст мусить знати bash» 🤡), то Nushell може стати для вас відкриттям!

Пан Шевцов питається, мовляв, «нащо не-посікс шел?». А я вважаю, що «заміна» посікс-команд власними — це навпаки чудово!

Усі ці казки про unix way, що, мовляв, «команда має виконувати одну функцію» — вже давно маячня. Там стільки напхали параметрів у кожну, що капець — однією функцією не назвати. Ще й не сумісні між лінуксом і BSD 😂 Утім, Nushell намагається йти шляхом unix, просто з чистого аркуша.

І та ж fish 🐟 дійсно відрізняється від умовної sh, просто не настільки сильно, як Nushell. І Powershell 🐚 теж (до речі, вона не віндова, а кросплатформна). Тож Nushell — всього лише ще одна серед багатьох. Є ще, наприклад, Elvish зі схожими ідеями. А значить, це питання звички й готовності щось змінювати.

Для змін, звісно, мають бути вагомі причини. Мої полягали якраз в тому, що це не сраний посікс, що команди не перевантажені мільйоном параметрів, що всі операції проходять зі структурованими даними, і можна нарешті забути про grep. Тобто це не косметичне покращення, а задизайнена з нуля система з урахуванням помилок і надбань минулих поколінь.

Пан Шевцов каже, що «можна було взяти Ruby». А я відповідаю, що Ruby значно гірше за Nushell для інтерактивного режиму. Чому? Тому що замало мати мову з REPL — нею ще має бути досить зручно писати команди, додавати параметри, робити інтерполяцію рядків, поєднувати команди ланцюжком, вкладати одну в одну, працювати зі шляхами врешті-решт тощо.

Тому ось моя вам порада: не слухайте ані мене, ані інших. Підіть і спробуйте самі. Тоді зрозумієте, що подобається саме вам, а не що вам напарили «професіонали» гг )) Врешті найефективніші інструменти — ті, якими ви вмієте користуватися.