Стендап Сьогодні

Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті

18.03.2023

Відновлення флешки з APFS, яку не відкривав macOS

Сьогодні займався, напевно, найстрашнішою побутовою компʼютерною задачею — відновленням даних з жорсткого диска. 💣

Як це трапилось. В мене був зовнішній диск, відформатований в APFS - файлову систему Apple. Диск був зашифрований - APFS це вміє на рівні файлової системи, дуже зручно.

Все було добре. Аж допоки мені не знадобилося перенести macOS на новий ноут. З наявних способів перенесення найшвидшим було через резервну копію - Ethernet під рукою не було, а USB-C виявився дуже повільним. Але для цього як раз потрібний вільний диск або хоча б розділ. Тут стала до нагоди ще одна можливість APFS - вона також вміє створити два розділи, що будуть розташовані в єдиному просторі на диску. Тобто, я зміг створити додатковий незашифрований розділ на тій самій флешці без фізичного виділення під нього місця. (До речі, не знаю, може Linux теж так вміє.)

Перенесення системи пройшло без проблем. Проблеми виникли трохи пізніше. Після чергового оновлення macOS моя флешка припинила відкриватись. Причому найстрашнішим чином — навіть Disk Utility не міг нічого про неї сказати, а зависав. Виправлення диска відмовлялося казати хоч щось, окрім загальної помилки. Я вже майже вирішив, що флешка (а точніше, зовнішній SSD з терабайтом цінних даних) незворотно поламана. Це було дивно ще й тому, що останнім часом я нічого не писав на ту флешку — окрім згаданої резервної копії, звісно.

Промінь надії майнув від утиліти Disk Drill, яка змогла показати каталог диска (хоча файли відновити не змогла). Це, а також дивна поведінка Disk Utility, дало мені ідею, що справа не в диску, а все ж таки в багах macOS. Довго чекав, що macOS виправиться, але з минулого літа нічого не змінилось.

Тому далі я знайшов оцю статтю, а через неї — драйвер apfs-fuse. Але на моєму Маці все до купи не зібралось, через те, що флешка була постійно зайнята Disk Utility, та драйвер FUSE не міг отримати до неї низькорівневий доступ. (FUSE це цікава технологія, відкриває можливість відобразити у вигляді директорії практично будь-що, до чого є драйвер. Наприклад, S3.)

Тому наступне, що довелось робити, це встановити Ubuntu на мій ігровий компʼютер (бо на M2 Macbook Air навіть не хочу пробувати.) Про це треба окремо розказувати, але головне, що на Ubuntu цей apfs-fuse з першої спроби скомпілювався, примонтував мою флешку, та без жодних заперечень скопіював з неї дані.(Пароль від диска він питає під час монтування.) Якось так:

sudo apfs-fuse -o allow_other /dev/sdc2 ~/external

Такі справи. Де macOS зависає, аматорський драйвер для Linux працює.

17.03.2023

Що робити з nvalid byte sequence in UTF-8

Сучасним програмістам не доводиться багато думати про кодування рядків. Так склалось, що UTF-8 переміг, та ми можемо вважати, що всі рядки та тексти будуть в UTF-8, та майже ніколи не матимемо проблем. Як приклад: всякий файл формату JSON за стандартом має бути в кодуванні UTF-8. І це чудово, бо на початку моєї карʼєри реально треба було обирати кодування — для кирилиці одне з двох чи трьох; для латиниці інше; та всі вміли перекодувати текст як треба.

UTF-8 класне кодування; для латиниці воно дуже компактне, але при цьому дозволяє використати більш мільйона різних символів, що легко покриває всі мови світу, а також емоджі, системні символи та все інше. Але недоліки UTF-8 - це змінна довжина символу та те, що не кожна послідовність байтів є дійсним рядком UTF-8. Перше заважає, коли треба порахувати “наочну” довжину рядка, або розбити його за символами. А про друге доводиться деколи згадувати. Класична дірява абстракція!

Якби будь-який рядок був дійсним UTF-8, то можна було б хоча б ігнорувати кодування та обробляти всі рядки в UTF-8. Для випадків, де не треба інтерпретувати зміст рядка, цього цілком достатньо — ну є незрозумілі символи та і є. Але ж ні — деякі рядки мають недійсні послідовності символів, та їх не можна інтерпретувати як рядки UTF-8 в принципі, принаймні, не без втрати цих недійсних послідовностей. Тому стандартні бібліотеки, коли натраплять на недійсний символ, не проковтнуть його, а викличуть помилку — в Ruby це класично nvalid byte sequence in UTF-8.

Ми стикнулись з цією проблемою при обробці DNS записів; вони не мають визначеного за стандартом кодування. Ясно, що в більшості випадків DNS містить рядки ASCII, який фактично є підмножиною UTF-8, тому ми їх обробляли як UTF-8 і все було добре. Проте знаходяться записи, що викликають помилку кодування. Тому доводиться всі рядки приводити до UTF-8 перед обробкою. В Ruby для цього є метод encode: string.encode(Encoding::UTF_8, invalid: :replace, undef: :replace, replace: '�'). Тільки так можна “вичистити” рядок від недійсних символів. Є ще метод force_encoding, але він нам не підходить — бо він не перетворює рядок, а тільки встановлює кодування. force_encoding корисний, коли відомо, що рядок не в UTF-8, а в іншому кодуванні.

16.03.2023

Мої трохи контроверсійні погляди на приготування кави вдома

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

Але взагалі, хотів поділитися своїми трохи контроверсійними поглядами на приготування кави вдома.

Найпростіший спосіб отримати вдома дуже хорошу каву — холодна екстракція. Купуєш пачку кави, молотої, приносиш додому, заливаєш в банці холодною водою. Через добу залишається тільки процідити через фільтр і все. Такий концентрат можна розбавляти холодною водою, гарячою водою, мінералкою, тоніком, молоком… В будь-якому разі, такий домашній колд-брю матиме дуже мʼякий та насичений смак, і з ним майже неможливо наробити помилок. Якщо все ж таки потрібна “нормальна” кава, то для дома найкраще підходить Aeropress. Аеропрес робить хорошу каву та головне, ним легко користуватись, та знов таки, складно помилитись. Ще аеропрес не прискіпливий до помелу.

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

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

15.03.2023

Як не поламати продакшн для всіх

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

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

Запуск інтеграційних тестів перед випуском нового коду теж не допомагає; це знайде регресії, але ж автоматизоване тестування теж обмежено передбачуваними сценаріями.

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

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

Далі, можна зробити зі стейджингу “версію раннього доступу”, яку можуть за бажанням використати ентузіасти. Чимало продуктів так і роблять. Навіть Apple декілька років тому почали випускати бета-версії своїх операційних систем, щоб покращити якість остаточної версії, яку побачать всі.

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

14.03.2023

Мій підхід до безперебійного перенесення даних

За останній час довелося декілька разів стикатися з потребою перенесення даних з одного місця на інше без перебоїв сервісу. Наприклад, вирішили поміняти базу для зберігання подій. Розробив для себе підхід, в якому впевнений.

Поміняти код, що пише дані, щоб він писав в обидва місця. На цьому етапі не важливо, що в новому місці немає старих даних — головне, що нові вже пишуться.
Стабілізувати систему — зробити деплой у всі місця, перевірити все що потрібно.
Визначити час, з якого ми певні, що нова база наповнюється в повному обсязі. Завжди буде проміжний початковий етап, коли не всі копії сервісу оновлені, або є помилки в новій схемі, або ще щось.
Видалити з нової бази все, що було раніше часу стабілізації.
Перенести зі старої в нову базу дані, які старіші за час стабілізації. Це для мене ключовий момент; встановлення чіткого розмежувального часу для перенесення даних — простий та надійний підхід. (Раніше я вигадував складну логіку дедуплікації — наприклад, порівнювання за унікальним ключем.)
Тепер в нас і стара, і нова бази наповнені та оновлюються. Тільки зараз можна переносити читання даних на нове місце. Якщо виникнуть проблеми — можна просто відкотити код.
Нарешті, коли нова база стабільно працює, можна вимкнути та вичистити код, що стосується старої бази. Найприємніший етап!

13.03.2023

Неявні перешкоди в розробці

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

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

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

12.03.2023

Порівняння крісел Steelcase Gesture та IKEA Markus

Нещодавно купив собі робоче крісло Steelcase Gesture. Це одне з найбільш шанованих крісел, та, відповідно, коштує купу грошей. Вагався з цим, без перебільшень, багато років. Хочу зробити огляд, порівнявши його з IKEA Markus - кріслом, на якому сидів багато років.

Декілька добрих слів про Markus. Це, на мою думку, крісло №1 з адекватної цінової категорії. Воно надійне — не поламалось піді мною років за сім, а я важу 90 кг. Воно легкодоступне — в Україні можна без проблем купити на Home Club). Воно точно краще, ніж крісла з JYSK або з місцевих меблевих магазинів — хоча б по надійності. Тож якщо потрібне хороше крісло, раджу саме IKEA Markus.

Чого мені в ньому не вистачало, це зручних підлокітників. По-перше, для мене вони були занизькі, та руки все одно висіли. По-друге, винесені надто вперед, через що крісло не заїжджало під стіл, та я не міг з прямою спиною дотягнутись до клавіатури. Тож, мабуть, не дарма я обрав крісло, яке славиться саме досконалими підлокітниками - Steelcase Gesture.

Порівняння. По сидінню - не відчуваю різниці. Сідниці як втомлювались, так і втомлюються — вставати корисно. По спинці — тут Gesture вміє вигинатись, щоб створити кращу опору натуральному вигину хребта. Хоча, в Маркусі теж непогана підтримка попереку. По механізму відхилення — тут суттєва різниця; Gesture можна налаштувати на баланс ваги, щоб воно відхилювалось “природно”, з рухами тіла. Тобто замість “сиджу прямо/відхилився” крісло готово прийняти будь-яке положення та залишатись в ньому. По підлокітниках — мрія здійснилась! Як мінімум, я можу підняти їх та відсунути назад — це те, чого в Маркусі не вистачало. Але взагалі, тут підлокітники готові зайняти положення, що відповідає потребам тіла на цю мить, та регулювати їх дуже легко. Після цих підлокітників на Маркусі незрозуміло, куди руки класти.

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

Ще знайшов на Реддіті дуже гарну табличку з порівняннями різних крісел — мені вона допомогла.

11.03.2023

Прості середовища для написання ігор

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

Це наштовхнуло мене на думку: коли я вчився програмувати - а ігри були одним з того що я робив на початку - то моїм “гейм мейкером” був MS DOS та Borland Pascal. Простота цього середовища дозволила навіть без досвіду робити доволі складні проєкти. Причому це було в 2001 році, коли час DOS давно минув, та всі вже грали в Counter Strike. Але якби мені в той час дали OpenGL або DirectX, навряд чи я опанував би їх так же ж, як і SetColor або LineTo з графічної бібліотеки Borland Pascal.

А зараз, коли роблять гру на кшталт Undertale, то беруть Game Maker. Хоча мені особисто хотілося б чогось це простішого, але орієнтованого на програмістів. От ще давно цікавить PICO-8 - це “віртуальна консоль”, тобто фактично середовище програмування - суворо обмежене в можливостях, та в цьому схоже на мої часи з Паскалем. До речі, пишуть для PICO-8 на Lua - про цю мову варто знати, бо вона розроблена для вбудовування в інші програми - компактна та безпечна.

10.03.2023

Як всиновлюють бібліотеки

Коли ми почали розробляти бібліотеки для інтеграції з нашим продуктом, виявилося, що наше брендове імʼя було зайняте. Я зголосився домовитись про передачу прав, та тому у нас зʼявився гем mailtrap та пакет NPM mailtrap. Замість того, щоб це були якісь mailtrap-sdk. Що в ізоляції, може, й прийнятне, але поруч з обманливим пакетом mailtrap створюватиме зайве непорозуміння.

Як це робиться. Знаходиш контакти автора, та пишеш листа. Звісно, для цього пакет має бути без активної підтримки. В нашому випадку минулий гем був з 2007 року та, здається, містив посилання на Rubyforge (в кого досвід по рубі 15 років, той памʼятає.) NPM-пакет був свіжіший, але все одно заархівований автором 2 роки тому. Втім, для пакета я додав у README посилання про те, що трапилось та де знайти старі версії. Загалом, для передачі прав достатньо було ввічливо попросити.

А от з Python все цікавіше, бо є цілий протокол передачі прав PEP-541. (Для мене це якийсь новий рівень бюрократії.) Треба зробити пул-реквест в особливий репозиторій за всіма правилами. Іронія в тому, що потім 3 тижні ніхто з команди на нього не відповідає. Непогана ілюстрація до принципу Agile “люди понад процеси” - замість довжелезної документації краще б була відповідальна команда підтримки. (Можна, звісно, домовитись з автором напряму.)

Почесна згадка - Go, бо там кожний пакет має URL. Тож конфліктів імен не може виникнути, та коли будемо робити свій, то це буде просто github.com/railsware/maltrap-go.

09.03.2023

Merlin Bird ID - Pokemon Go, але для птахів

🦜 Знаєте Pokemon Go? Так от, минулого року я дізнався про додаток, який вміє впізнавати птахів за співом - Merlin Bird ID. Для мене цей додаток перетворився на “реальну” версію Pokemon Go: почув спів незнайомої пташки, я вмикав розпізнання співу, та, якщо пощастило, “ловив” птаха у свій каталог. Розпізнання працює приблизно як з музикою, тобто будується спектрограма наявного звуку, та порівнюється з базою даних співів. Я ні в якому разі не орнітолог, та й взагалі, на початку мої знання обмежувались банальними горобцями та сороками. Але, Merlin працює так гарно, що за минулий сезон я дізнався чимало видів пернатої фауни.

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

З птахів, що я “спіймав”, найцікавіший — вивільга. Хоч ця пташка і яскраво-жовтого кольору, але я ніколи їх не помічав, хоча її характерний спів знайомий мені з дитинства. Та цікаво, що невдовзі після того, як я впізнав вивільгу програмою, то й побачити теж довелося — мабуть, бо знав, що шукати.

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

Раніше

Пізніше