Сіпласпластик

Я обожнюю скінченні автомати. Це штука, яку дуже легко втямити і яка потім вам знадобиться мільйон разів. Їх можна використовувати для опису процесів, автоматизацій на кшталт IoT або CI/CD, діалогів або поведінки НІПів в іграх, парсингу тощо. Завдяки їм зручно контролювати послідовність виконання чого-небудь, робити відновлення до попередніх станів, обробляти помилки. (Памʼятаю, у нас у MBUX був скінченний автомат для підʼєднання телефону до автівки по Bluetooth… на півтори сотні станів 😵‍💫 Гляньте якось BT-спеку заради цікавості). Але найулюбленіший мій спосіб їх використовувати — це звісно UI. Як усім відомо, найбільша проблема UI — це комбінаторний вибух станів. Якщо у вас купа «прапорців», які можуть по-різному впливати на поведінку програми, то інколи навіть утримати це все в голові важко. Але щойно ви робите скінченний автомат, усе стає значно легшим! На прикладі вгорі якраз такий для мого таймера на Pebble. На годиннику всього чотири кнопки, але уявіть собі код обробки натискання BACK без скінченного автомата: це був би довжелезний ланцюг if-else штибу «якщо таймер запущений, але не на павзі», «якщо таймер запущений і на павзі, але програється анімація скидання» і ще десяток таких. Натомість я описав окремі стани програми, і в кожному стані у кожної кнопки лише одна функція. Я писав на 💻, тому обробник натискання кожної кнопки перетворився на простий switch. Але бувають способи й красивіше. Наприклад, QML дозволяє описувати скінченні автомати декларативно. Обожнюю цей підхід. Також існує цілий окремий стандарт для опису скінченних автоматів в 💻 — SCXML; деякі тулзи вміють його читати, навіть той же 💻. Проте той же таймер мій — це дуже проста програма. Що робити, коли в'юшок стає багато? Ну, вочевидь робити більше скінченних автоматів! Доволі зручно робити їх ієрархічними. Уявіть типове IDE, в якому є «звичайний» режим кодінгу і є окремий режим зневадження — це ваш скінченний автомат верхнього рівня з двома станами. У кожного автомата є точка входу, напр

Там Basecamp навайбкодили CLI та TUI на 🦶 для своєї пошти HEY — нарешті можна не лише через їхню веб-версію заходити: https://github.com/basecamp/hey-cli. Я поки не пожалкував стосовно переходу на HEY — досі найзручніша мені пошта. Але відсутність IMAP чи якоїсь апішки трохи підбішувала. З цікавого: команди по дефолту пишуть JSON, якщо далі в ланцюжку стоїть ще щось:

Щось не злетіло з self-driving cars у автовиробників, еге ж? А стільки галасу було. Ну зате ШІ-шка відоси навчилася генерувати, дуже корисно: нарешті можу дивитися лайнячу рекламу зі штучними людьми 🫠 Ну нічо, помріймо, як могло б бути. Ми-то з вами програмісти, тому нам має бути очевидно, що оці всі лідари або, прости господи, камери 🚗 — це все дурня доти, доки на дорогах купа ідіотів за кермом. Натомість треба переробити все з нуля 🙂 Як у тому радянському анекдоті про сантехніка: «Все прогнило! Всю систему треба міняти». Щоб самокеровані автівки працювали, треба, щоб на дорогах були лише вони. Джедаї, що їздять 200 км/год, та інші любителі врум-врум — вам на ізольований трек. Якщо всі автівки керуються компʼютерами, то нема сенсу вже запарюватися спробами вгадати, що в який бік рухається. Натомість пропоную розробити протокол для прямого спілкування між автівками на середній відстані — скажімо, до 500 м. Нехай всі передають своє положення й вектор руху. Ну й, мабуть, анонсують свій намір: наприклад, змінити смугу. Тоді «сусіди» апрувлять і підлаштовують власний план руху під це. Для автобанів цього вже достатньо (хоча з тваринами питання відкрите). Та й з гіпотетичними перехрестями рішення тривіальне. Але в цілому з містами поскладніше — там тварин багато, зокрема людей. Доведеться канєш якось реагувати на раптові перешкоди, тож лідар все-таки стане в пригоді. З іншого боку, аварій все одно буде менше, бо цілий ланцюжок автівок зможе загальмувати одночасно, раптом шо. Та й зараз всі з телефонами все одно, тому можна прямо в них якісь маячки бахнути. Змінити все за ніч не вийде, звісно, тож все одно буде якийсь перехідний період. Скептикам нагадаю, що всього 130 років тому асфальтових доріг у світі взагалі майже не було, і нічого — набудували. Спершу зробімо окремі дороги, куди можна заїжджати лише на безпілотних автівках. В Європі тій же вже й так купа місць, куди можна вʼїжджати лише на дофіга екологічному транспорті, хоча далеко не всі такий мають, тож с

Зацініть рівень української служби підтримки. Жодних пояснень, заяв, перепитувань: «Не треба VPS? Ну то й до побачення!» — менше хвилини пройшло 😂

Якийсь час назад почав використовувати так звані passkeys для певних сервісів. На перший погляд, це безпечніше та зручніше за звичайні паролі, які можна забути, випадково розкрити тощо. А тут у вас є приватний ключ, збережений на пристрої, і публічний десь у тому сервісі, в якому ви хочете автентифікуватися. Важливо, що приватний ключ ніколи не залишає вашого пристрою й не передається по мережі на відміну від тих же паролів. Ну, в принципі шо я вам парю, якщо ви всі давно звикли до зв'язки приватного й публічного ключів в SSH. Причому з тим же 1Password ключ навіть не обов'язково зберігати у файловій системі. Але корпорати нас усіх знову переграли. Дружбан скинув статтю, автор якої налаштований не настільки оптимістично. І якщо чесно, я тепер теж. Розпишу коротко. Прикол у тому, що passkeys — це загальна назва для тупих споживачів типу нас. А стандарт WebAuthn насправді поскладніше, але ж хто ті стандарти читає, еге ж? Зокрема, WebAuthn розрізняє такі характеристики ключів як ті, що можна копіювати, і ті, що не можна; ті, які можна передавати, і ті, що ні; софтварні й хардварні тощо. Та найцікавіше починається на Attested vs Non-attested. У процесі автентифікації сервісу передаються всі характеристики вашого ключа. Фактично вони за бажання вже можуть заборонити вам використовувати ключі, які можна копіювати, наприклад. З іншого боку ви завжди можете написати (кого я обманюю? навайбкодити звісно) власну прогу, що передаватиме туди ті прапорці, які ви захочете. …Можете доти, доки сервіс не вимагає саме засвідчених (attested) ключів. Тоді все — приїхали. Знову буде якийсь реєстр «доброзвичайних» автентифікаторів, які можна використовувати, а решта йде лісом. Ми вже тисячу разів бачили цю схему. З останнього спадає на думку, як супервідкрита система Android, яка завжди дозволяла ставити будь-які програми звідки завгодно, одним рішенням ґуґла перестала такою бути. Віднині, як ви чули, без головного болю можна буде встановити APK лише від перевірених розробників.

Різноманітні програми, менеджери пакетів, компілятори, ШІ-агенти — все це засмічує дисковий простір на компі. Під вінду колись існував (досі існує?) CCleaner, під macOS є AppCleaner, PureMac, український CleanMyMac тощо. Під лінукс легше форматнути диск, мабуть, я хз 🤭 На початку року якийсь чувак (насправді автор менеджера пакетів Scoop) анонсував прогу, яка має чистити диск саме від кешів розробницьких інструментів — Reclaimr. У мене ще тоді закралася думка, що він її навайбав за вечір. Так чи інакше, проєкт, видно, не злетів, бо навіть завантажити з сайту бету вже не можна. Тому, сподіваюся, він мені пробачить, що я витягнув з його програми файл з правилами, де й що чистити. Тримайте теж, бо може стане в пригоді. Він далекий від повного, але це щось. Дивно, до речі, що ніхто досі не створив на ґітгабі якийсь відкритий реєстр місць, де накопичується сміття 🤔