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

Для 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. Зараз вже бачу, наскільки їхня спека мене обмежує. Думаю, згодом, може, зроблю власну надбудову.

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

Згодом зʼявився настрій то все покращити. А для цього треба розібратися, як у ресурсах гри що зберігається. На щастя основну роботу зворотної розробки вже проробили модери й навіть документували структуру файлів, тож мені лишалося цим скористатися.

Отже, в старих іграх на рушії Infinity Engine — Baldurʼs Gate, Planescape: Torment тощо — структура приблизно така: є key-файл (зазвичай називається chitin.key) і є тека data з низкою BIF-файлів (не дуже багато — штук 80, наприклад). Але фактично рушій працює з конкретними ресурсами: маю на увазі всілякі скрипти, зображення, описи анімацій, діалогів, звуки тощо. От їх якраз купа. Наприклад, у першій Baldurʼs Gate їх 37341 штука.

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

Отож key-файл — це бінарний формат, який описує всі ресурси, а також де саме вони лежать. А лежать вони в BIF-файлах. Кожний BIF — теж бінарний: фактично архів, у який напаковані різні ресурси, тобто файли й тайлсети. Розробники їх згрупували якось для зручності.

Я вже мільйон разів писав, як мені подобається Kaitai Struct 🏗, тож не обійшлося без нього й цього разу. Писати бінарний парсер по готових спеках — якесь дивне задоволення, трохи медитативний процес навіть. Сидиш ото, пиришся в hex-редактор, щоб переконатися, що ніде не сплутав big-endian з little-endian — кайф! Хоча цього разу парсери конкретно для key та BIF сів писати мій дружбан.

А мені ж треба було вже працювати з конкретним типом ресурсів. В ідеалі я хотів би читати їх прямо з key+bif-файлів так само як це робить гра, але на той момент єдиним виходом було експортувати їх вручну іншим інструментом в локальну файлову систему. Постає питання: як написати код так, щоб потім не треба було його адаптувати?

Я пишу на 🦶 і спочатку думав абстрагувати якось процес читання в якийсь Reader абощо, а потім передавати його у свої обробники всюди. Але це якось кволо. До того ж якщо подумати, будь-який файл — це вже Reader, а точніше io.Reader. Тож гіпотетично можна написати свою імплементацію. Правда, виявилося, що для Kaitai одного io.Reader замало — треба ще io.Seeker, щоб можна було читати з будь-якого офсета.

Тут я натрапив на лібу spf13/afero, яка ніби трохи спрощувала все це. Тож я просто завʼязався на інтерфейс afero.Fs усюди у своєму коді, і на той момент працював з локальною файлухою. А згодом написав свою «віртуальну» файлову систему, яка дає змогу працювати з усіма запакованими ресурсами гри «прозоро» для користувача, хоча насправді я читаю їх прямо з BIF-файлів без проміжного видобування. І вуаля: підмінив одну фс на іншу, а воно досі працює 😎

Повільнувато трохи тільки 😅 Наприклад, видобування ~1200 файлів на 25 МБ загалом у мене на M1 Max ішло 2,5 хвилини 😂 Довелося зайнятися профілюванням, яке, маю зазначити, в Go дуже легко додати в програму! Посиділи трохи з тим же друганом, знайшли найболючіші місця, і тепер видобування всіх ресурсів на майже 2 ГБ загалом триває близько 12 секунд.

У підсумку скажу (знову) пару слів про Go 💻: я ще починаючи з торішнього Advent of Code писав, що мова мені не подобається. І в принципі це досі так. Вона якось деревʼяно відчувається, немає в ній наче фану зовсім. Але наскільки ж легко й зручно в ній доводити справу до кінця! От просто сідаєш і пишеш без виїбонів, а воно потім працює, так ще й компілюється в один бінарь для будь-якої системи. І тулінг зручний. Можливо, це наразі єдина розробка від ґуґла, яку я поважаю.

На торішньому Advent of Code я з певним успіхом намагався розвʼязувати задачі щодня різними мовами, зокрема на Haskell 💻, 💻, Nushell 🆕, Swift 🕊, Python 💻, Red 🔺, 💻, Nim 👑, 🦶, Elixir 💻, Dart 💻, SWI-Prolog 🦉, 💻, Janet 👩‍🦰, Crystal 🔮, 💻 й 🕸.

Не певен, чи цього року я робитиму так само, але накидайте мені, може, ще пропозицій? Напишіть, яку мову програмування на вашу думку варто спробувати й чому ✍️🧐

Там 🌌🌌🌌🌌 у стімі з 9️⃣2️⃣ знижкою (усього 119₴). Хто ще не пограв — це ваш шанс )

До речі про Steam 💨

Днями вирішив зробити собі невеличку базу ігор, яку заповнювати, звісно, руками не будеш. Так виявилося, що у стіма є відкрита API-шка!

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

let gameId = '1328670'
let info = http get https://store.steampowered.com/api/appdetails?appids=($gameId) 
  | get $gameId 
  | get data

І далі вже можна дивитися, шо там:

> $info.name
Mass Effect™ Legendary Edition

> $info.genres
╭───┬────┬─────────────╮
│ # │ id │ description │
├───┼────┼─────────────┤
│ 0 │ 1  │ Action      │
│ 1 │ 3  │ RPG         │
╰───┴────┴─────────────╯

> $info.ratings.pegi
╭──────────────┬──────────────╮
│ rating       │ 18           │
│ descriptors  │ Violence     │
│              │ Bad Language │
│              │ Gambling     │
│ use_age_gate │ true         │
│ required_age │ 18+          │
╰──────────────┴──────────────╯

Або навіть отак:

> $info.supported_languages | split words | 'Ukrainian' in $in
false  # 😭

(Підіть, може, хоча б ШБТ 💙 попросіть у дискорді, щоб вони переклали… Ех.)

Я собі так навіть знятки екрана всі стягнув. Важать вони, до речі, доволі дофіга: на ≈150 ігор вийшло близько 900 МБ 🤯 Треба, мабуть, у WebP конвертнути.

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

Уважний читач (так, ти 🫵) міг побачити, що URL-параметр в запиті називається appids, а не appid. Однак ні — одразу декілька передавати не можна, бо тоді їхній сервер повертає HTTP 400. Єдиний виняток — це комбінація з фільтром price_overview, яка працює:

> http get https://store.steampowered.com/api/appdetails?appids=1328670,1091500&filters=price_overview | transpose -d | rename id val | select id val.data.price_overview
╭───┬─────────┬────────────────────────────────╮
│ # │   id    │    val.data.price_overview     │
├───┼─────────┼────────────────────────────────┤
│ 0 │ 1328670 │ ╭───────────────────┬────────╮ │
│   │         │ │ currency          │ EUR    │ │
│   │         │ │ initial           │ 5999   │ │
│   │         │ │ final             │ 479    │ │
│   │         │ │ discount_percent  │ 92     │ │
│   │         │ │ initial_formatted │ 59,99€ │ │
│   │         │ │ final_formatted   │ 4,79€  │ │
│   │         │ ╰───────────────────┴────────╯ │
│ 1 │ 1091500 │ ╭───────────────────┬────────╮ │
│   │         │ │ currency          │ EUR    │ │
│   │         │ │ initial           │ 5999   │ │
│   │         │ │ final             │ 5999   │ │
│   │         │ │ discount_percent  │ 0      │ │
│   │         │ │ initial_formatted │        │ │
│   │         │ │ final_formatted   │ 59,99€ │ │
│   │         │ ╰───────────────────┴────────╯ │
╰───┴─────────┴────────────────────────────────╯

Тепер можна нагенерувати собі сторінок в обсідіані або кудись ще покласти 😎

#TIL на ґітгабі 🐈 в налаштуваннях можна ввімкнути режим високої контрастності. Значно ліпше виглядає!