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

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

08.02.2024

Асинхронні функції з синхронними назвами

Досить багато часу провів в пошуках помилки в програмі на SwiftUI, яка була спричинена функцією removeAllPendingNotificationRequests. Ця функція видаляє всі заплановані локальні сповіщення.

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

Але чомусь мої сповіщення ніяк не зʼявлялись. Я вже все перевірив: зміст, розклад, дозволи, запуск на симуляторі та на справжньому телефоні. (До речі, багато систем в iOS погано працюють на симуляторі — але сповіщення не одна з них.)

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

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

…Щоб виправити помилку, можна отримати перелік запланованих сповіщень функцією getPendingNotificationRequests (до речі, яка приймає колбек!) та видалити конкретно їх. Або, в такому разі, можна вже й не видаляти, а пропускати при створенні.

07.02.2024

Людський фактор інтеграції

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

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

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

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

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

06.02.2024

Pkl - нова мова конфігураційних файлів від Apple

Нещодавно Apple випустила Pkl - мову програмування для генерації конфігураційних файлів. Взагалі ця тема мене займає, бо найкращі з моїх рішень — це шаблони jq для JSON та YAML з шаблонами Go - я б щасливий був замінити. Тим паче побачив [відгук] про те, що Pkl - один з найкращих внутрішніх інструментів Apple.

Що ж воно таке? Сама мова чимсь нагадує за базовим синтаксисом Terraform (тобто HCL). В ній є як повноцінні засоби програмування (навіть класи імпорти), так і типізація. Єдине, що через семантику конфігурації трохи заплутано зрозуміти, де що (наприклад, обʼєкт може успадкувати інший обʼєкт.)

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

Звідки скрипт бере дані? Раджу роздивитись документацію про ресурси. Наприклад, зі змінних оточення. Або навіть з запитів HTTP (наприклад, з метаданих ECS). Додати до цього повну по Тюрінгу мову, та можна реально замінити мій генератор YAML на Go. (Або генератор JSON з jq на Баші, який ще складніше підтримувати.)

До речі, про інтеграцію з Go (одну з офіційних інтеграцій.) Інтеграція дозволяє завантажувати дані прямо з файлів Pkl у структури. Тобто використати Pkl як конфігураційну частину свого сервісу. Пропонується кодогенерація, проте вона генерує тільки структурні типи. Решта коду інтерпретується — тож інтеграція Pkl тягне за собою цілий інтерпретатор. Тут я поки не бачу сенсу (хоча може з досвідом зʼявиться.)

05.02.2024

Особливості ORM CoreData/SwiftData

Робота з ORM на платформах Apple дуже відрізняється від ActiveRecord, до якого я звик. Йдеться про CoreData - офіційну ORM від Apple, яка може синхронізуватися через iCloud, проміж інших переваг рішення “від першої сторони”.

CoreData - це справжня обʼєктна база даних. Це попри тому, що як сховище вона використовує SQLite. Але шар SQL повністю схований під абстракцією — та, до речі, має незручну в прямому доступі структуру, якщо вже знайти базу на диску та відкриті в клієнті SQLite.
А так, все, що ми робимо в CoreData, робиться через обʼєкти. Створення, видалення, асоціації. Атрибути обʼєктів не обмежені примітивними типами.
Для взаємодії з базою використовується контекст моделі. Це клас, який вміє як діставати з бази обʼєкти, так і зберігати. Але більше цікаво те, що контекст є ніби вікном в базу. Зберігання обʼєктів відбувається не по одному, в ActiveRecord, а всім контекстом. Аналогія така, що база — як шафа, а контекст — як робочий стіл: дістали зі шафи все потрібне, обробили, та повернули назад.
Через це CoreData виглядає більш… цілісно; код більше займається бізнес-логікою, ніж механікою роботи з базою. Це мені подобається. Втім на початку трохи лячно, бо будь-яка ненавмисна зміна до об’єкта буде збережена. Інтуїція працює зворотно від ActiveRecord: там треба не забути зберегти, а тут — не проґавити зайву зміну.
Якщо без оцінювальних суджень, то просто цікаво мати досвід з різними системами, щоб уявляти що взагалі можливо. Наприклад, думаю, на фронтенді підхід з контекстом був би досить зручним.

04.02.2024

Стохастичний тайм-трекінг на SwiftUI

Сьогодні наполовину для розваги, наполовину для діла спробував зробити на SwiftUI реалізацію одного особливого тайм-трекера. Особливий він тим, що, замість ручного ведення журналу чи автоматичного збору даних, трекер питає тебе, чим зараз займаєшся. А щоб це не було передбачуваним — інтервал запитів буде стохастичним, тобто випадковим. Інколи через пʼять хвилин, інколи через дві години. Випадковість моменту робить такий трекер неупередженим (якщо завжди заносити саме те, що робиш зараз.) На довгому проміжку часу статистика дає правдивий розподіл часу.

Це все не я придумав — йдеться про TagTime - зроблений чимало років тому розробниками сервісу Beeminder. TagTime має вигляд купки скриптів на Perl та, відповідно, здатний працювати тільки на десктопі.

А в мене ідея зробити застосунок для Apple Watch та скористатись повсюдністю годинника. У WatchOS є така цікава можливість. як long look для повідомлень — фактично цілий інтерактивний екран, доступний безпосередньо при перегляді сповіщення.

До того ж використання бази даних CloudKit та універсальності SwiftUI дозволяє легко зробити застосунок, в який можна заносити з десктопу, з телефону чи з годинника — де зручніше. А інтеграція Apple Health може автоматично логувати сон та тренування. Причому виглядає так, ніби все це не потребує багато зусиль, динамічного програмування і так далі. Ну, подивимось.

03.02.2024

JIT, чому Ruby повільний, та як він може стати швидшим

Читав нещодавно статтю про те, як реалізацію парсера на Ruby зробили швидше за С. Хотілося прокоментувати, що це в принципі значить. (Все це також стосується майже будь-якої динамічно типізованої мови, будь то JavaScript, Python, і так далі.)

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

Наприклад, в С структурований тип має зафіксований перелік атрибутів. А в Ruby ми можемо додати чи видалити атрибут в будь-який момент. Так само можемо взагалі передавати обʼєкти різних класів у функцію та користуватись duck typing.

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

Втім, в реальних програмах структури даних не змінюються часто. Тож нормальний код на Ruby теж можна було б привʼязати до фіксованої форми даних та компілювати так само як і C. Саме це й робить JIT - виявляє фрагменти коду, що працюють зі стабільними структурами даних, та компілює їх.

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

02.02.2024

Масові операції в OpenSearch - практика

Масове оновлення скриптом — може, не така вже й хороша ідея. Працює це повільно. Що таке повільно — поясню: припустимо при типовій роботі база отримує 1000 нових документів на хвилину. Логічно, що в такому разі ресурси нашої бази розраховані на таку швидкість індексації (плюс стільки, за скільки ми переплачуємо для резерву). З цього випливає, що масове оновлення буде відбуватися десь з такою самою швидкістю — теж 1000 документів на хвилину. На мільйон документів піде 17 годин. І це оптимістична оцінка, бо оновлення старих документів повільніше, ніж утворення або оновлення свіжих. Я б радив придумати, як уникнути оновлення та спиратися на дані, які вже є.
Трансформації — теж не дуже швидка операція, бо під час трансформації OpenSearch виконує по одному пошуку на кожну комірку агрегації. На мільйонах документів та сотнях тисяч комірок виходить теж довго. Можливо, дні стовідсоткової завантаженості процесора.
З прозорістю в OpenSearch все складно. Зрозуміти, скільки залишилось трансформації, можна хіба за поточними результатами. А ще вона може зупинитись з помилкою. А дізнатись, що то була за помилка, можна тільки з журналу, бо ззовні видно тільки помилку “верхнього рівня”, типу “помилка трансформації” а в неї схована причина - “не вдалося виконати пошук”, а в неї першопричина - “запит має надто багато пунктів”. Все це можна побачити в журналі. А яке це має відношення до моєї трансформації (бо в ній запит не такий вже й складний!), та як виправити — то вже без форумів не розберешся.
Одним словом, за зручністю та… “міцністю” до PostgreSQL тут далеко. І це такий момент БД, який я не часто чую в обговореннях — якщо до PostgreSQL майже завжди можна ставитись до бастіону надійності, де нічого непередбачуваного не відбудеться, то OpenSearch все ж тільки ще один сервіс, зі своїми багами та сюрпризами.

01.02.2024

ARF - автовідповідач про спам

Давно не писав нічого про SMTP. Є така прикольна поштова технологія, що отримувач позначає лист як спам, то відправнику надходить про це спеціальний звіт. Називається звіт Abuse Reporting Format (автор його, до речі, родом з України.)

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

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

Є тільки один нюанс — з великих поштових сервісів ARF надсилають тільки Yahoo та Microsoft. А левова частка пошти надходить GMail, який ніяких звітів не надсилає. Ба більше, в GMail взагалі немає способу дізнатись долю листа. Чому так? Як я розумію, бо GMail не хоче, щоб спамери отримували інформацію про успішність своїх розсилок. Отакої — технологія гарна, але толку з неї мало.

31.01.2024

Масове редагування в OpenSearch

Після реляційних баз масові операції в OpenSearch виглядають дуже дивно. Головне, що треба зрозуміти — тут немає ніякої однорідності між документами; якщо в SQL ми знаємо, що операція UPDATE успішно закінчилась або не була застосована взагалі, то в OpenSearch можна відразу планувати, що успіх буде частковим. А хто звик працювати з розподіленими системами — напевно, не побачить в цьому нічого дивного.

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

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

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

Тепер, зовсім неприємне: так звана “динамічна типізація” атрибутів (dynamic mapping). Річ у тім, що в кожного атрибуту є тип, який впливає на індексацію та доступні операції. Цей тип можна вказати заздалегідь, але якщо цього не зробити, OpenSearch призначить тип автоматично. Це ніби добре, але тип атрибута неможливо змінити без повної переіндексації, тобто копіювання документів в новий індекс з правильними типами — а потім, ймовірно, копіювання назад, якщо назва індексу для вас має значення. Тому, якщо у вас документи мають передбачувану структуру, я раджу вимкнути динамічну типізацію (вказати "dynamic":"strict") - тоді OpenSearch відмовить в індексації документів з невідомими атрибутами. Що набагато краще, ніж індексація аби як.

30.01.2024

Паралельні обчислення в Ruby

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

Взагалі, в одному процесі Ruby може одночасно працювати тільки один потік коду. Це те, що називається GVL - Global VM Lock, раніше відомий як GIL. Віртуальна машина Ruby не розрахована на паралельне виконання.

Міф: раніше в Ruby були “зелені” потоки, а тепер системні, тож сучасний Ruby здатний на паралелізацію. Так, клас Thread створює системні потоки — які можуть бути запущені паралельно на всіх ядрах процесора. Все одно — через GVL всі окрім одного потоку будуть заблокованими.

Правда: щоб досягти справжнього паралельного виконання, потрібно створити декілька процесів (наприклад, через Process.fork). Це працює тому, що кожний процес — це окрема копія віртуальної машини, з власним GVL. Але, звісно, ми втрачаємо спільний простір змінних; окрім того, створення процесів повільне та не підходить для “локальної” паралелізації.

Всі серверні програми на Ruby використовують як процеси — щоб залучити всі ядра процесора, так і потоки — щоб ефективно обробляти ввід/вивід.

Сучасний нюанс: тепер є ще клас Ractor. У кожного Ractor свій GVL. Магії немає — рактори, як і процеси, ізолюють свої змінні. Зате рактори створюються швидше процесів (кожний рактор — окремий потік) та мають зручний механізм обміну даними. Рактори дозволяють виконувати на Ruby справжні паралельні обчислення.

Та, останній момент, про бінарні бібліотеки: звичайний виклик функції з бібліотеки нічого з GVL не робить та на логіку не впливає. Проте тут є спосіб відімкнути GVL, викликом rb_thread_call_without_gvl. Це відкриває шлях для паралельного виконання іншого потоку, якщо такий є. Звісно, без GVL не можна робити нічого з Ruby, зате можна робити внутрішні обчислення чи ввід/вивід.

Раніше

Пізніше