На торішньому 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 на ґітгабі 🐈 в налаштуваннях можна ввімкнути режим високої контрастності. Значно ліпше виглядає!

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

Прочитав пару тижнів назад у пана К. (в «Мамкіному Архітекторі») допис із закликом писати в коментарі, хто чим користувався. І там хто про шо — від make до Jenkins. Воно й дійсно різниця не завжди очевидна, бо і те, й інше може виконувати приблизно ту саму роботу, а саме: запускати якісь скрипти, що викликають тули, туди-сюди перекладають файли, качають щось з інтернетів тощо.

Раніше я вже казав, що люблю, коли можна повністю зібрати й запустити проєкт однією командою, проте, так було не завжди. Користувався я й TeamCity, і Jenkins і ще бозна-чим. Коли GitHub Actions зʼявилися, я одразу на них перестрибнув через їхню (нібіто) простоту. Тож білд-система в мене щось компілювала базово, а потім вже Actions хоп-хоп файли кудись з теки у теку поклали, заархівували або викликали скрипт для інсталятора й оце все. Іншими словами, побудова проєкту була розмазана між білд-системою і CI.

Це незручно з низки причин.

По-перше, CI-ні скрипти дуже важко запускати локально: на вашому CI-сервері є власне оточення, нерідко доволі крихке 😆 гг, а також є купа додаткових штук для якоїсь там безпеки та ізоляції (щоб не вийшло, що дві джоби якось конфліктують) — це все важко, та й не сильно треба повторити локально. І якщо частину важливої роботи робить саме CI, то в якийсь момент може виявитися, що ніхто не знає, як той проєкт взагалі зібрати без нього. Небезпечна залежність, ще й потенційно «вузьке місце».

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

Тобто є сенс якомога більше речей виводити на рівень нижче (що корелює з загальним розумінням і практиками) — у білд-систему. Чи можна було б наробити 🐈 Actions для виклику окремо компілятора, окремо компонувальника, окремо тулів для підписування бінарів ключем? Та можна, але чомусь ніхто так не робить. Беручи це до уваги, стає очевидним, що інші задачі також краще виконувати на рівні білд-системи: встановлювати залежності, пакувати документацію, збирати інсталятори тощо.

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

Урешті в тому проєкті ми досягли відносного успіху. Головна частина нашої джоби на CI мала отакий вигляд:

- name: Create package
  run: qbs build config:release profile:github-${{ matrix.os }}-ci qbs.architecture:${{ env.QBS_ARCH }} -p megaapp-${{ matrix.os }}-installer

Буквально одна команда, яка все збирає і пакує. Але необхідні залежності вже були в оточенні (компілятор + Conan + Qt). А зараз з Xmake навіть це не обовʼязково, бо він вміє все сам стягувати.

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

Якийсь чувак «зібрав докупи свої нотатки» про розробку UI-фреймворків. Вийшло понад 200 сторінок 😯 Доведеться полистати, бо це одна з моїх найулюбленіших тем.

(Посилання підрізав у пана Лютікова в «Шось про айтішку»).

Прочитав десь фразу:

30+ років — це той вік, коли з'ясовується, що ти навіть дихав усе життя неправильно.

Але сьогодні буде не про дихання, а про чистку зубів 🦷🪥

В дитинстві мені показали «алгоритм»: повозюкав туди-сюди щіткою, сполоснув рота від пасти, виплюнув — ну я так роками й робив, а шо.

Деякі сумніви почали зʼявлятися з появою в мене іригатора. Це такий прикольний пристрій, який фігачить воду під тиском. Дуже раджу, до речі. Так от я просто додав його у свій алгоритм: якщо все одно споліскувати рота водою від пасти, то чого б не робити це іригатором? Логічно? Логічно.

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

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

Мене, щоправда, не одразу осяяло. Ще десь рік-другий я в такому режимі й продовжував користуватися. А потім я-я-як збагнув! Треба ж їх місцями поміняти! Спочатку іригатор, потім щітка з пастою, потім сполоснув, щоб паста ротову порожнину не розʼїдала своєю мʼятою. І прям усе на свої місця встало!

Ну, майже все, точніше. Подумав я про це ще рік, і почав схилятися до того, що якось тупо наносити пасту й тут же її змивати. У чому сенс, себто? Ще й зуб один став трохи чутливіший до холодного, на що стоматологиня якраз порадила пасту лишати на зубах. Капе-е-ець! Тепер-то реально все на своїх місцях. Це ж як автомийка: навряд чи ви спочатку наносите всілякі захисні шари на тачку, а потім миєте її від бруду.

І раптом виявилося, що усі ці написи на зубних пастах типу там sensitive repair або whitening — це не стовідсоткова маячня рекламна. Воно справді діє й робить краще, якщо тільки дати йому змогу. А деякі пасти навіть не настільки й мерзенні, щоб їх лишати на зубах.

Закладаюся, що ви-то все життя правильно робите. І що все це давно відомі факти, які ґуґляться за 2 хвилини. Однак річ у тім, що ґуґлити-то й не спадало на думку ніколи: ти просто робиш те, що ніби знаєш, як робити. А деякі ще й примудряються інших навчати. Дивовижно все-таки, наскільки люди схильні за деревами лісу не бачити. І наскільки звичка впливає на наше сприйняття 😬

Цікаве спостереження про впровадження інструментів в європейському автомотіві (і, певно, ще багато де).

От робили колись всі дизайни для UI у фотошопі, і це здавалося зручно. А потім зʼявився Sketch, і всі дуже швидко перейшли на нього, бо він закривав цілу низку потреб: по-перше, це вектор, а не растр, по-друге, можна бібліотеку компонентів створювати було, перевикористовувати їх для різних скрінів тощо. Щоправда, тільки на macOS 🙁 Згодом зʼявилася Figma 💻, яка певні речі ще сильніше спрощувала, як то, наприклад, спільна робота над одним документом, можливість користуватися навіть у бравзері тощо.

Всі миттєво на неї перестрибнули… але не автомотів 🙁 Чому? Ну бо дані десь у хмарах, а Figma не запарювалася зробити варіант з виділеним сервером абощо. А раптом дизайн майбутньої системи кудись не в ті руки потрапить (промисловий шпіонаж досі існує, я думаю), раптом хвіґму ту вашу зламають — гігантські втрати грошей потенційно. Отак воно роками тягнулося, і все нарешті узгодили, домовилися й вирішили мігрувати в неї. Що ж змінилося для цього? А нічого! Дані досі в хмарах 😆 Просто криза підтискає, конкуренти в Китаї не сплять (а роблять чік-чік і в продакшн™), а німці досі скетч-файли пересилають імейлами.

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

Тепер же в нас всюди ШІ для програмування. Окрім автомотіва звісно. Чому? Ну бо дані в хмари кудись ідуть 😂 І я не про написання якихось критичних систем в автомобілях — там ясно, що є купа сертифікацій, які просто не пройдеш зі згенерованим ШІ кодом (а якщо пройдеш, і потім щось «вистрілить», то це ще гірше) — ні, я про внутрішні тулзи навіть. Спочатку було повністю заборонене будь-яке використання. Згодом почали потроху послаблювати: можна отримати ліцуху на умовний копайлот чи клод, щоб потестувати, але спочатку треба створити заявку з детальним описом, нащо воно тобі, підписатися кровʼю, що використовуватимеш ШІ максимум для прототипів, які йдуть у смітник, почекати на апрув членів спеціальної ради, й тоді можна буде навайбкодити свій перший hello world.

Чи вважаю я, що це погано? Ні, не вважаю, бо дійсно є ціла низка нюансів, яким творці генеративних ШІ не приділяли значної уваги. Наприклад, використання чужих робіт для навчання своїх ВММ-ок, захист даних досі не надто переконливий, захист від нових векторів атак через ШІ-агентів тощо.

Чи знаю я, як правильно варто було б розвʼязувати питання активнішого впровадження ШІ? Ні, на це в мене теж рішення нема. Всі занепокоєння дійсно актуальні, ризики реальні й далі по списку.

Але що я знаю, так це те, що років за 3–5 жодні з цих питань так само не будуть вирішені. Навіть доволі ймовірно, що ще гірше стане. Але хтось з босів в автомотіві скаже: «та пофіг! впроваджуймо всюди ШІ!» — бо ринок змусить.

От тоді покатаємося 😂 (А взагалі я б, мабуть, не радив купувати моделі автівок пізніше за 2025 рік, бо хто його зна 😂)

Колись давно тимлід на роботі дав мені задачу зробити фічу на Perl 🧅, а сам пішов у відпустку. Я намагався розібратися з тим перлом, але мені настільки не зайшло, що не зміг себе змусити. Та й у щойно створеній команді ніхто мови знав. Тож я плюнув і переписав всі наявні на той момент напрацювання на Python 💻 + фічу, яку мав зробити. (Python насправді теж ніхто не знав, але всі хутко розібралися).

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

Perl, як відомо, це write-only мова. Я знаю людей, які добре в ній тямлять і роблять чудові речі, однак, я точно не серед них. Не люблю, коли в мові програмування забагато якихось мутних символів. Чого не можна написати нормальними словами‽

Взагалі хз, нащо я це все вам розповідаю. Ні, на перлі я не почав писати й не планую.

⁂

О, до речі ж розвʼязав учора задачі першого дня Advent of Code на Uiua 💻. Оцініть мій код 👇

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

Обідня перерва на той час добігла кінця, тож дав розібратися з цим Claude Code. Він на диво непогано себе показав! Прям дуже довго щось дебажив та врешті досяг результата. Щоправда, розвʼязок був занадто не елегантний — з трьома додатковими функціями. Довелося викинути й написати своє рішення по-людськи. Я переконаний, що цією мовою можна написати ще краще, та я задоволений навіть цим результатом.

Сьогодні не про Advent of Code. Вчора часу на це не було — наклепав якесь сумнівне рішення на SWI-Prolog 🦉, про який вже раніше писав. Додати нема чого.

Натомість розповім про #тулзи для дво- та тристоронніх дифів. Спробував нещодавно Kaleidoscope.app: доволі красива програма, є прикольні фічі й усе таке, але хз — лишилося відчуття сируватості… Тож коли тріал закінчився, просто видалив її.

За ці роки пробував багато різних програм. Але досі не бачив нічого кращого за Araxis Merge, яким користувався вперше ще років 20 тому. Єдина проблема, що ліцуха коштує 270 баксів — якось забагато для інструмента, котрий не те щоб критично часто трапляється в пригоді. Тож порівняння всі робив просто у VS Code 💻.

А в неділю зайшов до них на сайт і побачив, що вони дають ліцензію тим, хто робить внески в open source. Тож написав їм на е-пошту, скинув приклади своїх PRʼів у той же Xmake, та й власні напрацювання деякі є — і шо ви думаєте? Наступного дня відповіли мені й дали Pro-ліцуху на рік 🥰

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

Закладаюся, що більшість з вас не чула про мову Rye.

Я досі мрію, що для моєї улюбленої мови Red 🔺 колись вийде повноцінний реліз. А допоки цього не трапилося (і насправді вже не трапиться), звертаю увагу на будь-що інше, де REBOL 💻 вказаний як джерело натхнення. І якщо Red — це буквально той самий REBOL з додатковими фічами, то Rye зроблений скоріше «за мотивами», хоча спільних рис достатньо.

По-перше, він так само гомоіконний: між даними та кодом немає жодної різниці — це все лише блоки слів, які набувають якогось конкретного значення в контексті. Але якщо в ліспах списки на кшталт (+ 100 500) обчислюються одразу, хоча цьому можна запобігти додавши якийсь апостроф або ще щось залежно від діалекту, то в Rye (як і в REBOL) навпаки — нічого само по собі не обчислюється, а треба робити do { _+ 100 500 }.

По-друге, у мові фактично нема якихось ключових слів або спеціальних конструкцій. Усі if, for, while і ще купа усіляких — це звичайні функції, які приймають або скалярні значення, або ті ж блоки. Виходить, що той do зазвичай вже є десь усередині них, тож на практиці у своєму коді бачиш його не часто.

Ну а ще виходить (по-третє), що можна створити контекст, в якому цих усіх функцій не буде взагалі, зате можна наповнити його власними штуками. Це активно використовується для створення діалектів. Останні є фактично eDSL, і вони дуже різноманітні, що як добре, так і погано з обʼєктивних причин.

Чисто з погляду на синтаксис Rye трохи сумнівний місцями. Не на мій смак. Трохи приємніше за ліспи, але досі гірше, ніж REBOL чи Red. Думаю, вся справа в дужках: в ліспах використовуються переважно круглі, і їх багато, тут же їх менше, але вони фігурні, а в REBOL дужки квадратні! Що це значить? Правильно — що не треба тиснути Shift! Оптимізація процесів 😀

Ще є всілякі приколи, як можна записувати одні й ті самі слова по-різному:

add: pfn { a b } { a + b }  ; pure btw!
div: pfn { a b } { a / b }

div ( add 3 9 ) 6    ; 2.000000
( 3 .add 9 ) .div 6  ; 2.000000
3 .add 9 |div 6      ; 2.000000

Тулити щось прямо до дужок не можна — обовʼязково ставити пробіл. Хз, мені не дуже це подобається.

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

Сам інтерпретатор до речі на 🦶 написаний, що потенційно дозволяє легко кроскомпілювати програми під будь-які системи, але я не перевіряв.

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