Я, певно, був останнім, хто порадив пану Шевцову 👆 подивитися на #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 — нею ще має бути досить зручно писати команди, додавати параметри, робити інтерполяцію рядків, поєднувати команди ланцюжком, вкладати одну в одну, працювати зі шляхами врешті-решт тощо.

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

Понад двадцять років тому я навчився друкувати текст наосліп і відтоді кайфую (бо зекономив тижні часу!). Суперкорисна навичка.

І мова не тільки про очевидні переваги, як-от швидкість друку або відсутність необхідності мати підсвітку клавіатури.

Річ у тім, що формування навичок і звичок — це буквально єдиний спосіб ефективно підвищити власну багатозадачність. Бо якраз завдяки цьому виконання задачі переводиться зі свідомості в підсвідомість.

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

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

Мені знадобився десь місяць (приблизно по годині в день), щоб почати друкувати текст кирилицею. Латинкою я тоді ще не вмів, але й потреби не було, бо англійську я не знав достатньою мірою, а з кодом поспішати нема куди. Утім згодом навчився і нею. (А ще пізніше опановував Colemak, у процесі розучився користуватися QWERTY, і довелося навчатися знову 😅).

І головна перевага сліпого друку — це те, що… не доводиться думати про сам процес друку. Мозок споживає 0 мілісекунд на обмірковування, яку кнопку натиснути. Тому коли ви пишете електронного листа, нотатку, документацію, код, повідомлення в чаті, промпт для ШІ-шки — ваша свідомість сфокусована лише на конкретній думці, а не способі ввести її в комп'ютер.

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

Як же замахали всі ці контори охуївші!

Отримав листа від Spotify, що вони знову підіймають ціну передплати на 20% майже, хоча буквально торік вже підіймали на стільки ж! Пишуть:

Підвищення ціни на Premium необхідне для того, щоб ми могли й надалі вдосконалювати наші продукти та функції.

Так а де вдосконалення-то?! Як радило мені русню щотижня, так і далі радить. UX значно погіршився субʼєктивно за останні років 5 (упевнений, що за їхніми метриками-то все в порядку, а мене бісить прям). Ще й подкастами своїми всратими постійно мені UI засмічують. Додали аудіокнижки, але пофільтрувати хоча б за мовою не можна — у мене там тупо німецькою все, якою я не володію.

(Взагалі ототожнення мови й регіону — це окремий треш, за який треба засилати хоча б на рік в Африку якусь, де люди англійською не говорять, абощо. Але це окрема тема для розмови).

Або, буває, купуєш якусь програму, яка тобі до вподоби, а вона після автоматичного оновлення, від якого не можна відмовитися, стає лайном. З іграми таке теж трапляється: от, наприклад, 👾 цього року ретроспективно нову EULA на свої ігри розкатала, як той же Borderlands 🎮.

У мене на телефоні дохуїльйон програм стоїть «на всяк випадок». Ну наприклад, для купівлі квитків на громадський транспорт, яким я користуюся два рази на рік, або для оренди самоката (раз на два роки) тощо. Хєрня, яка дуже дратує — все постійно тебе розлогінює. Деякі проги вже за пару днів це роблять. Але ще гірше, це коли ти запускаєш прогу, а вона каже: не можу працювати — треба оновлення. І най би це стосувалося лише суто онлайнових штук, так ні ж! Геть посказилися зі своїми оновленнями.

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

З останнього Scamsung так зробив. У них є лінійка телевізорів Frame, які косять під картину на стіні. У мене якраз такий. І на ньому давно існує магазин картин — можна купувати ліцензію на показ чиїхось творів. А можна й свої світлини завантажувати. Ну я, звісно, пішов та стягнув собі з інтернетів Рєпіна 👆 (тим паче в магазині його все одно нема). А зараз на форумах вже пишуть, що після останнього оновлення в декого навіть для встановлення власних світлин треба передплату 🤯 І таких випадків я особисто можу назвати пару десятків, а насправді їх мільйон!

Що з цим робити, я хз. За змоги — не платити таким тварюкам. Але змога не завжди є, особливо з залізом. Щодо софта… можна принаймні сидіти на якихось self-hosted штуках, проте, опенсорсні продукти традиційно лайно в сенсі UX переважно, ще й підтримувати інфраструктуру власноруч доведеться.

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

На ютубі є тіпок на імʼя Луїс Россманн, і він на тему клятих монополістів багато чого парить — рекомендую, якщо цікаво. Він навіть власну вікі створив (і підтримує грошима її розвиток), щоб збирати всі подібні випадки, як я вище писав: https://consumerrights.wiki/ (Спробуйте з цікавості вбити в пошук свій улюблений бренд 🙂)

Отже, подивилися ми (переважно не я, а друган) на деякі інші системи складання проєктів. Я вже писав про те, чим Qbs замахав і які маю критерії для вибору. А сьогодні розповім про декілька кандидатів.

Build2 — це щось для відірваних від реалій людей шанувальників усього на 💻 (ця система написана повністю цією мовою). Згадати хоча б той факт, що для build2 нема готових бінарів, а натомість треба їх спершу власноруч зібрати з сирців, причому бажано тим самим компілятором, що й свій проєкт! 🤡 Білд-скрипти їхні — це як шел, помножений на мейкфайли (не зміг вирішити, що гірше, тож узяв обидва). Коротше, мʼяко кажучи, ду-у-уже на любителя, і я точно не серед них. Ще й, здається, якісь ретроградні росіянці пишуть. (Проте якщо чисто за фічами дивитися — то насправді вельми непогано).

Швидесенько глянули на Premake. Він прикольний тим, що там скрипти на 💻, все просто й лаконічно. Я б навіть сказав, що занадто просто. На жаль збирання проєктів на 💻 — це біль. Особливо з #QML. Особливо, коли декілька бінарів. Особливо, якщо це потім треба все скласти в application bundle на macOS. І ще насправді Premake нічого не збирає 😆 Він генерує солюшн під VS або ті ж білд-скрипти для Ninja. Комусь це норм — врешті ninja саме для цього і створили — але мені не норм. Однак з усього сьогоднішнього списку він найприємніший.

Попарилися з Meson, і навіть щось вийшло. Але таке… У них там якась власна декларативна мова трохи дивна, хоча й геть проста. І видається, що не можна писати власні кастомні правила — можна хіба що додати custom_target, в якому викликати щось зовнішнє. А моя задача зробити навпаки! Хочу, щоб не треба було купу додаткових тулів встановлювати, бо це ускладнює CI. Якась базова підтримка Qt там вже є й доволі непогана, але мені цього замало. Якби не це, то можна користуватися — і приємніше за CMake 🤮. Документація теж норм, хоча місцями доволі… необширна. Короч, нам ця система не підійшла кропаль, але якщо у вас чисті плюси або, наприклад, 💻, то спробуйте, бо справляє враження стабільного продукту.

З Bazel (у народі — «Василь») знайомство пройшло найшвидше. Чувак вирішив почитати, як у ньому правильно встановити бажаний стандарт C++ для компіляції, і зʼясував, що… ніяк блять 😂 Принаймні кросплатформно. Тобто рекомендований шлях це зробити — руками прописати світчі для компілятора під кожну систему. Красно дякую! Одразу відчувається рука UX-спеціалістів з ґуґла. Інший дружбан пару місяців тому тестував кодінг-здібності Gemini Pro, попросив того створити проєкт на Bazel і дуже радів, коли ШІ-шка страждала над «цим висером інженерної думки, так само, як [він] колись» (цитата). «Карма в дії», — каже 🙂 Ото, власне, на цьому все й скінчилося з цією системою. Так, там підмножина Python 💻 (Starklark), усілякі фічі круті тощо, але організм відторгає — що поробиш.

Краєм ока глянули ще на метівський Buck2. Там до речі теж Starlark, як і в Bazel. Але воно наче заточене під гігантські монорепи й усе таке, тож не наш випадок.

Вибираємо далі.

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

Річ у тім, що більшість програмістів… не тямлять в них 💡 Так, навіть нативщики (про веб і мова не йде).

По-перше, пересічний програміст не вибирає білд-систему. На роботі таке рішення зазвичай приймає хтось рангом повище: архітектор там якийсь або хоча б техлід. Та і як часто у вас на роботі починаються нові проєкти зазвичай? Ви приходите в компанію, а проєкт там вже триває, ви йдете — а він досі є. Білд-система вже вибрана й працює. Трапляються поодинокі випадки міграцій, як ото в нас була з QMake на CMake, але це рідкість.

Якщо ж ви робите пет-проєкт, то берете те, з чим вже знайомі, тобто те, що було на роботі. Тобто вибір теж відсутній.

По-друге, мало хто з програмістів підтримує або модифікує процес побудови. Докинути в білд пару нових файлів або лібу — це одне, а прям поміняти щось — то зовсім інше. Цим займається переважно якась одна, ну максимум дві людини, які розібралися в цьому трохи краще. Навіть в коментарях у мене писали, що в них так влаштовано все. І, мовляв, «навіть мейкфайли норм, нащо ще щось?» Але той, хто бачив хоч раз білд з десятка-другого не дуже вдало переплетених мейкфайлів, потім пів року чілить на рега́бі з ПТСР.

По-третє, програмісти не паряться щодо фінального постачання. Багато хто чогось переконаний, що зона їхньої відповідальності закінчується в момент, коли коміт запушений. Як результат: від білд-системи треба лише, щоб проєкт запускався з IDE або з термінала. А сучасні IDE й білд-системи цей процес намагаються максимально спростити: вони «за кадром» докидують шмат власного середовища — якісь змінні оточення, якісь теки, де шукати ліби, яких у користувача не буде, тощо. Я протягом років з такою ментальністю у своїх командах доволі багато боровся зі змінним успіхом.

Якщо мова, наприклад, про настільний застосунок, то мій критерій такий: воно має запускатися подвійним клацанням з провідника/файндера. Скільки раз таке було, що з IDE все працює, а просто з теки ні — навіть не полічити вже.

По-четверте, є ціла низка питань, над якими програмісти навіть не замислюються. У тому ж прикладі з настільною програмою до них можна віднести:
• правильна структура тек у складеній програмі. На вінді, наприклад, всі dll-ки мусять лежати поряд з exe-шником, а в macOS-бандлах своя особлива структура, де все по різних теках, і треба правильно прописати rpath, щоб бінарі знали, звідки вантажити бібліотеки. На лінуксі теж своя атмосфера, яка залежить від того, в якому вигляді ви програму розповсюджуєте.
• додавання іконки програми. На вінді треба в ресурси запхати ico, на макосі покласти в бандл icns і прописати в plist, на лінуксі… по-різному. Причому у вас на вхід пачка png-шок різного розміру від дизайнера. Звідки ті ico та icns брати?
• правильне встановлення 3rd-party залежностей. Треба спочатку з'ясувати, а які вони, ті залежності. Без чого програма не працюватиме? Потім динамічні бібліотеки розкласти по своїх місцях, тули по інших; якщо залежите на опенсорс, то треба ліцензії всі у своїй програмі перелічити десь тощо.
• інсталятори… Ви все зібрали, розклали по теках правильно, а тепер треба з цього зібрати дистрибутив. DMG на macOS, якийсь Inno/NSIS/Wix на вінді, DEB, RPM, AppImage і Flatpak на лінуксі.

І врешті треба зробити, щоб усе це відбувалося автоматично. Тобто треба CI. Яке там середовище? Звідки там мають братися всі ті ваші зовнішні залежності, якщо їх бракує? Якщо вони встановлюються звідкись щоразу, то це ж довго, треба кеш або контейнери якісь. А як збирати під різні платформи? Кроскомпіляція чи по серверу на кожну? Чи віртуалки?

Багато які складні фреймворки намагаються все це від користувача приховати і якось роблять по-своєму. І це чудово, бо можна не паритися хоча б через якісь з цих питань… доки не виникає особлива потреба зробити щось інакше. І тоді раптом виявляється, що програмісти, які 10 років пишуть на C++ і QML, навіть не розуміють, як QML-рушій шукає й завантажує їхні ж плагіни, котрих у нашому проєкті сотні (будь-які збіги з реальними людьми випадкові 😅)

Ось приблизно з таких ☝️ причин я хочу білд-систему, яка робитиме мені все викликом однієї команди 😊

Трапився на очі отакий бравзерний рушій vaev, написаний повністю на 💻. З цікавого: в репозиторії нема жодного хедера, бо все на модулях 😲 Тож якщо комусь хочеться дізнатися, який на вигляд Modern C++, підіть і подивіться — цей проєкт є непоганим прикладом.

Хедерів нема, але пара інклудів усе ж є, бо там залежність на фреймворк Karm (уперше бачу), хоча він теж переважно на модулях; а Karm своєю чергою є частиною операційної системи Skift (уперше бачу). Все написане мовою C++.

А збирається воно білд-системою CuteKit (уперше бачу 😆), яка вже на пайтоні. При цьому опис проєктів для складання — тупо в JSON 💻

Давно я не писав нічого про 💻. На жаль і самою мовою теж, шо вже поробиш.

Але трапилася стаття: Індія розробила свій власний «вітчизняний» 32-бітний процесор Vikram для ракет і супутників. І найцікавіше тут те, що під нього вони розробили власний набір інструментів для програмування на Ada й уже працюють над компілятором для 💻. Всі-то звикли вже, що сішний тулсет пишеться найпершим, а тут навпаки!

Воно й зрозуміло. Якби я програмував щось для космічних супутників, то теж би на C дивився в останню чергу. Ada дозволяє писати значно виразніший і безпечніший код з формальною верифікацією коректності (і при цьому мова не створює відчуття якоїсь незавершеності, як деякі сучасні «конкуренти»). Короч, Ada — ваш бро.

До речі, у TIOBE вона зараз на 13-му місці, а в PYPL на 12-му, що значно вище, ніж більшість з вас могла очікувати. Ada обійшла, наприклад, усілякі Ruby й Kotlin, а залежно від індексу ще й Go або PHP.

Буквально нещодавно ще виходила стаття про Ada українською: там і про відновлення популярності мови, і про українську спільноту, і про miltech. Гляньте, якщо цікаво.

Коли роками пишеш один проєкт, особливо у великій команді, то багато речей лишаються «за кадром», бо в тебе є твій шматочок коду й твоя задача, а що там поза ними — вже не так цікаво. Або ж цікаво, але часу розбиратися нема. Там свої спеціалісти приведуть усе до ладу.

А коли команда до десяти людей і проєкти невеличкі, ще й стартують частіше, ніж раз на пʼять років, то треба їх якось початково сетапити, нерідко власноруч. А якщо це не «повноцінні» проєкти, а прототипи — то критично важливо це ще й робити швидко, бо прототипи можуть писатися по декілька штук на місяць/тиждень/день (а потім іти у смітник 🥲).

І для себе я відокремив мінімальний набір найважливіших штук, які намагаюся налаштувати зі старту:
1. Білд однією командою.
2. Лоґування.
3. Конфігурація.
4. Тести.

З першим усе наче зрозуміло, бо я вже неодноразово писав у попередніх дописах.

Друге — це прям must have. Я зазвичай не користуюся зневаджувачем з низки причин. По-перше, у C++ з ними поганенько. По-друге, колись давно компонувальник просто не міг зібрати дебажний білд нашої програми для телефону, бо він був 32-бітний, а в нас там ліби по 800+ мегабайт (шаблони розгорнулися ггг). Тож я звик користуватися лоґами. І бажано, щоб це був не cout або print, а нормальне лоґування з часом тощо. А якщо ще й у файл пише, то взагалі збс. І щоб для користування не треба було навколо танцювати, а достатньо було додати один #include або import у будь-який файл.

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

Тести… Їх народ не любить писати. І я не любив і досі не люблю. Але згодом я збагнув, що не люблю цього робити не тому, що це якось складно, нецікаво або не дуже потрібно, а тому, що якогось хєра це завжди дуже марудно! Обовʼязково треба поприсідати, щось кудись прокинути, десь ввімкнути, прописати тощо. Отже: сетапимо все з самого початку, робимо порожній тест, який нічого не перевіряє, але він є — і вже люди зможуть далі робити за зразком. (Це як перлина: щоб вона сформувалася, треба якусь пилинку, навколо якої потім вже нашаровується перламутр). А далі замість того, щоб додавати в програму якесь тимчасове лоґування проміжних значень, запускати програму, дивитися, чи правильне там значення, чи ні — замість усього цього просто робимо тест, який робить те саме: перевіряє проміжні (чи які вам треба) значення! Зручно й швидко 🙂

І коли насетапив щось подібне вже 5–10 разів, то починаєш замислюватися, як би цей процес прискорити: мутиш собі якісь шаблони проєктів, використовуєш певну структуру тек, одні й ті самі бібліотеки тощо.

Добре, коли сама мова тобі допомагає це робити. Наприклад, в тому ж Nim 👑, памʼятаю, тести дуже легко писати. Прямо в тому самому файлі навалюєш їх — і все працює. Або в Ruby ♦️ та Crystal 🔮 теж класно.

А днями дізнався про прикольну фішку мови Chapel: там є конфігураційні сталі та змінні! Буквально додаєш config перед оголошенням

config const steps = 42;

як отут 👆, і бем! — жодних додаткових рухів не треба. Тепер можна або ключем значення передавати: myapp --steps=100500 — або через конфіг-файл. Так, цукор, але люблю таке. (А от у сусідньому чаті, де я це побачив, чувак якийсь підгорів з того config і доводив, що це кепська фіча. Хз.)

Насправді окрім цих чотирьох пунктів є ще пʼятий, який я намагаюся завжди мати — так званий hot reload. Але це вже точно окрема історія.

Ну добре, годі тягнути кота за хвіст. Я вже писав, як ми втомилися від Qbs, писав про інші системи, які ми спробували. І врешті-решт я зупинив свій вибір на Xmake.

Як і Premake, ця система базується на 💻, але на цьому спільні риси закінчуються. Чи закриває Xmake усі мої потреби? Абсолютно ні. У ньому купа недоліків. Попри це він задовольняє деякі з моїх критеріїв, які мені критично важливі, і я вважаю, що цей компроміс того вартий.

В Xmake уже є підтримка збирання 💻-програм, але вона вкрай кепська: якоюсь мірою працює для умовного Hello World, але не для повноцінної програми. Нам довелося написати декілька власних правил — і наскільки ж це легше робити, ніж у Qbs! Хоча прихованих проблем теж удосталь. За той місяць, протягом якого ми вʼяло колупаємо Xmake, я вже зарепортив декілька багів і створив низку запитів на фічі.

Шила в мішку не втаїш, тому одразу зазначу один з найпомітніших нюансів щодо розробки Xmake… Це китайський продукт 🙂 Тому на ґітгабі нерідко можна побачити тікети на кшталт отакого: xmake在mingw下无法编译. Не кривитиму душею — це трохи лякає. Не хотілося б, щоб воно збирало програму разом зі вбудованим бекдором 😅 З іншого боку декілька багів, які я знайшов, я сам же й виправив. А ті, шо не виправив, автор пофіксив сам протягом доби-двох. Отже, до цього взагалі жодних нарікань: сирці зрозумілі, виправляти не складно, на ревʼю тільки валідні коментарі — все швидко й адекватно.

Опис білда на Xmake переважно декларативний, але можна (інколи треба) й імперативні скрипти писати. Є підтримка різних компіляторів і навіть мов, є якась підтримка модулів з C++20, усілякі там віддалені й розподілені білди, кому треба, створення пакетів з готовими програмами тощо.

Одна з найвагоміших переваг Xmake — я нарешті зміг позбутися всратого Conan, бо в Xmake є вбудований менеджер пакетів з централізованим сховищем, але й створити власне дуже легко — це просто 💻-репозиторій. Я вже створив окреме для наших бібліотек. До речі, якщо пакет збирається чимось іншим, наприклад, тим же сімейком, то це не проблема — все легко інтегрується.

Інша вагома перевага: можна створити пакет з кастомними правилами для збирання. Саме це я й намагаюся робити, бо мене замахало їх копіпастити між проєктами. Потім в одному щось покращив, в інший не переніс, і навпаки… Дуже дратує. А тепер я можу просто додати залежність на правила — і жодного головного болю від ґіт-сабмодулів або ще чогось. Ну, принаймні в теорії, бо на практиці того ідеалу, що в мене в голові, я ще не досяг.

Зараз я вже бачу, що багато з того, що мені треба, в Xmake відсутнє. Не було правил для автоматичної генерації Qt-ресурсів, qmldir-файлів, компіляції шейдерів (це ми написали все), немає підтримки InnoSetup, AppImage або Flatpak, macOS DMG тощо. З іншого боку я нарешті бачу шлях, як це написати власноруч, не чекаючи, що хтось з розробників системи збирання це зробить.

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

Звісно, є відчуття, що я проміняв одну мутну систему на іншу. Типу, чого б уже просто не взяти CMake 🤮‽ Але у підсумку мені здається, що якраз-таки цей вибір був дуже прагматичним. І попри купу недоліків, мої потреби Xmake закриває краще.

Писав же нещодавно про важливість на самому початку проєкту закласти можливість використовувати в ньому конфіги й логування.

Для C++ на жаль бібліотек, які б мені реально подобалися, для цього нема.

А от на Python 💻 у мене є пара улюблених. Закладаюся, ви про них знаєте, але якщо ні, то прошу 🙂

Перша — це Dynaconf. Вона дуже фічаста. Читає конфіги й із файлів, і зі змінних оточення, і бозна-звідки ще. Підтримує купу різних вхідних форматів для налаштувань: TOML 💻, YAML 💻, JSON 💻 тощо. Я зазвичай користуюся YAML, бо руками його писати найприємніше. (І шо ви мені зробите, га‽). Також прикольна фішка з шарами — постійно нею користуюся. (Це як у VS Code 💻, де є сталі глобальні налаштування, є користувацькі і є проєктні. І кожні з них нашаровуються на попередні й перевизначають деякі поля. Знаєте ж?) Так от цим зручно користуватися, коли, наприклад, при розробці ви підʼєднуєтеся до якихось локальних серверів, вмикаєте додаткове логування, якісь ще фічі, API-токени читаєте з локального файлу, а в продакшні використовуєте віддалені сервери зі своїми ендпоїнтами, вимикаєте різні «дірки» для дебагу, токени берете десь з Vault тощо. Один раз налаштували профілі, а потім між ними перемикаєтеся — зручно.

Друга ліба — це structlog. Взагалі зазвичай коли кажуть про структуровані логи, то мають на увазі, що замість звичайного тексту в журнал записуються JSON-обʼєкти, причому часто не в локальний файлик, а в спеціалізований сервіс на кшталт Elastic. Але в мене таких юзкейсів нема.

Насправді ж ідея в тому, що ваш логер оперує не текстом, а обʼєктами. А це значить, що можна робити купу прикольних штук! Наприклад, можна додавати щось у контекст, і цей контекст прикріпиться до повідомлення. У мене ось є тестовий бот для тґ, в якому окремий middleware прикріплює в контекст повідомлення інформацію про команду, яка прийшла від користувача (якщо це саме запит з командою):

async def add_command(self, event, data) -> None:
    match data:
        case {'command': CommandObject(prefix=prefix, command=command)}:
            structlog.contextvars.bind_contextvars(command=f'{prefix}{command}')

Ну й низка інших схожих штук. (Нижче є зняток екрану).

Якщо ви весь час оперуєте обʼєктами, то це значить, що можна побудувати ланцюжок додаткових обробників. Це приблизно як в нормальному (тобто 🆕) шелі, де ви через жолоб переливаєте з однієї команди в іншу не просто потік байтів, а структуровані дані. Завдяки цьому повідомлення, що логуються, легко додатково якось обробити: агрегувати в них щось, пофільтрувати, змінити структуру — будь-що. Наприклад, уявіть ситуацію, що при розробці ви хочете в терміналі бачити якомога більше даних в логах: різну зневаджувальну інформацію, параметри функцій, тіло запитів тощо. Але в продакшні цього робити не можна, бо логи у вас пишуться в якусь базу, і туди можуть випадково потрапити приватні користувацькі дані. Якщо логер у вас текстовий, то доведеться якісь милиці ставити, а якщо структурований, то ви легко можете написати окремий фільтр, який ті дані видалить або замаскує.

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

processors = [
    structlog.contextvars.merge_contextvars,
    structlog.processors.add_log_level,
    structlog.processors.StackInfoRenderer(),
    structlog.dev.set_exc_info,
    structlog.processors.TimeStamper(fmt="%Y-%m-%d %H:%M:%S", utc=False),
    structlog.dev.ConsoleRenderer()
]

І нижче на знятку — те що отримуємо на виході (там кольорові штуки в кінці повідомлень — це контекстні змінні, які додаються моїм кодом автоматично! Дуже зручно).

Якщо знаєте якісь прикольніші ліби або аналогічні для інших мов, то напишіть мені в коментарі, будь ласка )

Стикнулися тут з проблемою: текст для перекладу гри — це просто здоровезний список рядків у довільному порядку без жодного контексту. Виходить, що перша фраза в діалозі може бути з аідійшкою #23456, а наступна вже #76543 (тобто між ними 50 тисяч інших текстових шматків). Отже, дуже складно зробити переклад узгодженим — купу енергії потребує.

Але ж у самій-то грі ці рядки якось повʼязані в суцільний діалог! А значить, є шанс цю інформацію звідти видобути. Цим я й зайнявся.

Про сам процес розкопування ресурсів гри я згодом ще розповім, а зараз скажу лише, що мені це вдалося. Половина справи зроблена.

А інша половина — це відображення цих даних. Тож сів і зробив інструмент для перегляду діалогів. Про фічі вже розповів у відосі, а тут напишу про технічну складову.

У вебі я не тямлю, але знайомий топовий чувак @marktanashchuk порадив мені SvelteKit, і мені норм зайшло. Замість ноди я взяв Bun, бо він принаймні швидко працює, до того ж підтримує 🕸 з коробки.

Майже все написав мені 🐈 Copilot (з Claude 4). За три дні на це пішла приблизно половина місячної норми токенів 😆 Закласти фундамент проєкту було найскладніше. ШІ-шка традиційно згенерувала дохуїльйон коду, зробивши низку некоректних припущень. Довелося це все видаляти й іти дрібнішими кроками. Згодом в пригоді став 💻-сервер для DevTools, завдяки якому можна ШІ-агенту прям сказати: «Піди й сам подивися, що за лайно ти наробив», — а він іде, дивиться й виправляє (а завдяки хот-релоаду й перевіряє одразу).

Всі діалоги насправді експортовані в JSON Canvas, який виявився відкритим форматом. Рендер графа робиться через D3 в SVG з домішками HTML через <foreignObject>. Потім з цього збирається статичний вебсайт, який я через GitHub Actions розгортаю на Cloudflare Pages.

Завдяки цьому всьому тулза не залежить від конкретної гри. На прикладі у відео діалоги з першої Baldur's Gate, яка звісно вже давно перекладена. З 18 МБ вхідних даних на виході отримав 56,5 МБ сайт, тобто роздуло його втричі. Зате не вимагає виконання жодного коду на сервері взагалі.

На перших порах розробки, коли мій рендер був ще такий собі, використовувати JSON Canvas було дуже зручно, адже будь-який експортований діалог можна було переглянути в тому ж Obsidian. Зараз вже бачу, наскільки їхня спека мене обмежує. Думаю, згодом, може, зроблю власну надбудову.