Карти

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

MapLibre — організація, яка робить бібліотеки, щоб рендерити карти. Для браузерів використовує WebGL, для мобілки і десктопа Metal і OpenGL. Бібліотеки зазвичай форки MapBox, який колись був open source, тому багато де сумісний з ним. Серед спонсорів AWS, Meta та інші.

OpenFreeMap — проєкт, який роздає векторні тайли безкоштовно, без реєстрацій і обмежень. Можна або використовувати публічний сервер або захостити самому. Проєкт одного пана Zsolt Ero, який вірить, що роздача тайлів не має коштувати дорого як вона коштує зараз. Під капотом у цього сервісу тільки nginx який роздає 300млн статичних файлів-тайлів (ого!)

pyupgrade

Найшов прикольний інсутрмент, який пройдеться по python коду і оновить його на сучасніший варіант.

Для прикладу, може підправити типи:

```

-def f(x: List[str]) -> None:
+def f(x: list[str]) -> None:
...

```

Або може переписати .format на f-рядки:

```

-'{foo} {bar}'.format(foo=foo, bar=bar)
+f'{foo} {bar}'

```

для велких і старих проєктів прям треба

🔗 github.com/asottile/pyupgrade

Brioche

Натрапив на статтю, де автор крок за кроком розказує як можна так упакувати програму для Linux, щоб всі її залежності були в одній папці і при цьому програма залишалася динамічно скомпонована (dynamically linked). Так автор підводить до ідеї, яка закладена у новому пакетному менеджері brioche (хліб топ 👩‍🍳). Мені стаття сильно сподобалося, тому ділюся з вами 🥰

🔗 Portable, dynamically linked packages on Linux

wasm and i

У мене є невеликий пакет-обгортка навколо pdfium для node.js. Недавно мене в issues на GitHub запитали чи можна запустити пакет у браузері. Сам pdfium скомпільований у wasm бінарник, тому я подумав, що проблем не має бути і чому б не додати таку можливість. Тим паче, що я хотів давно спробувати зробити pdf viewer поверх цього пакету.

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

Ключова проблема в тому, що браузери не вміють завантажувати .wasm через тег чи import в JS. Треба вручну цей бінарник завантажувати через fetch і передати у WebAssembly клас. Це напевно не проблема зробити у власному проєкті, типу покласти десь у папку /public чи /assets, вміст якої доступний по якомусь відомому шляху, і звідти викачувати. Але це точно проблема, коли я пишу сторонню бібліотеку. Я нічого не знаю на якому хосту і по якому шляху у мого кінцевого користувача будуть розміщувати assets проєкту. Найкраще, що можна в цьому варіанті зробити це дати шлях до .wasm файлу в моєму пакеті на диску і вже нехай сам користувач розбирається зі своїм бандлером, що з ним робити і куди його класти. Мінус в тому, що користувачі майже завжди прийдеться додатково налаштовувати власний бандлер, щоб це запрацювало. Це напевно не проблема зробити у власному проєкті, типу покласти десь у папку /public чи /assets, вміст якої доступний по якомусь відомому шляху, і звідти викачувати. Але це точно проблема, коли я пишу сторонню бібліотеку.

Інший варіант це взяти .wasm бінарник, конвертувати його в base64 і запхати в код ?. Щось типу такого:

```
export const wasmBinary = "SGVsbG…";

```

Далі я як автор пакету можу вже не просити користувача нічого передавати в мій пакет, а під капотом самому розкодувати base64 і передати wasm файл у WebAssembly клас. Відчутний мінус, що розмір пакету збільшується на 30%, в моєму випадку це ще +2мб. Наскільки б костильно цей варіант не виглядав, але він тупо найпростіше виглядає для користувача — ніяких проблем з бандлером, ніяких URL, все за тебе робить пакет, тобі треба тільки імпортувати пакет:

```
import { PDFiumLibrary } from '@hyzyla/pdfium';

await PDFiumLibrary.init();

```

Вже під кінець найшов гарну статтю, де автор розповідає про ці варіанти, але в більших деталях, тому рекомендую Recommendations when publishing a Wasm library

Пароль треба?

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

Користуюся Bitwarden як менеджер паролів. Так от він час від часу блокує сховище і просить ввести master пароль, щоб його розблокувати. От прям вчора сиджу у кавʼярні, а Bitwarden просить пароль і через біометрію не дає розблокувати. А що якщо камера спостереження пише відео й охоронець зможе відновити всі мої паролі? Ну і ця ж проблема не унікальна тільки для менеджера паролів, бо кажуть, що пошту найкраще перевіряти пошту в якійсь кавʼярні за макбуком. Ви купили каву, відкриваєте ноутбук, а у вас там сесія в Gmail закінчилася ☕️

Наступна історія теж повʼязана з менеджерами паролів. Не на всіх сайтах і не у всіх мобільних додатках мій менеджер паролів уміє підставляти пароль у форму. Тоді приходить копіювати цей пароль і вставляти вручну у поле для пароля. Звісно ж після копіювання цей пароль живе собі спокійно в буфері обміну. Декілька раз так забував про пароль у буфері обміну і вставив його кудись куди не треба, наприклад у поле для повідомлення у Slack чи десь у коді — "Г'юстоне, у нас там помилка ~~xA9owEaQyPd@!k~~, ой, NoSuchKey" ?

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

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

JSONB statistics

PostgreSQL Stories: From slow query to fast—via stats | Render Blog

Історія оптимізації простого запиту в PostgreSQL від компанії Render.

```
SELECT e.id
FROM events e
JOIN postgres_dbs db
ON e.data ->> 'serviceId' = db.database_id
LIMIT 1;

```

Таблиця events великих розмірів, postgres_dbs — відносно невелика. Є індекси і на db.database_id, і на e.data ->> 'serviceId'. Але JOIN працює довго.

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

Вирішується проблема створенням вручну статистики по полю JSONB (вперше почув про таку можливість):

```
CREATE STATISTICS events_service_id
ON (data ->> 'serviceId'::text)
from events;

```

Мені відразу ж захотілося піти передивитися всі запити, які якось шукають по JSONB. Ще по цій темі нарив ще таку статтю PostgreSQL - JSONB and Statistics

stdout buffer

Пишу розширення для VSCode і хочу запустити програму xcodebuild для збірки iOS проєкту. Сам xcodebuild працює досить довго і постійно друкує в stdout результат збірки. Тому мені треба дати зворотний зв'язок користувачу і постійно друкувати логи з xcodebuild в інтерфейсі VSCode.

VSCode розширення в мене написане на Node.js, тому в коді це виглядає приблизно так:

```

import { spawn } from ‘child_process’;

const child = spawn('xcodebuild’, […]);

child.stdout.on('data', (data) => {
console.log(stdout: ${data});
// … далі виводимо в vscode
});

```

Запускаю це скрипт, але, по власних відчуттях, дані в stdout прилітають з якимись затримками, ніби є якась пауза між викликами функції, яка обробляє stdout. Я відразу ж подумав, що це якась проблема з node.js і поліз гуглити.

На мій подив, виявилося, що це стандартна поведінка всіх програм, які залежать від glibc і ця поведінка не залежить від того хто намагається зчитати stdout: чи то Node.js, чи то Python. Сам glibc обробляє вивід приблизно так: якщо програму запущено з термінала, то у stdout вивід буде потрапляти кожен раз, коли у буфер потрапляє символ нового рядка \n. В інших випадках вивід буде буферизуватися поки не назбирається достатня кількість символів. Часто розміру цього буферу 8 кб, тобто поки не назбирається 8 кб у буфері, то батьківський процес не зможе отримати дані з stdout.

В моєму випадку я запускаю xcodebuild не з термінала, а з VSCode, тому вивід програми віддається рівними шматками й саме тому виникає відчуття затримки, бо поки xcodebuild не надрукує близько десятки рядків, щоб наповнити буфер, node.js не отримає відповіді.

Як це обійти? Сама програма, яку викликають, в моєму випадку xcodebuild, може контролювати чи потрібно буферизувати вивід. Для прикладу, в Python є змінна оточення PYTHONUNBUFFERED, яка вимикає буферизацію для stdout. Інший популярний варіант це створити псевдотермінал (pty) і вже з нього запустити команду. Тоді в stdout дані будуть потрапляти після символу нового рядка. Але треба бути обережним з псевдотерміналом, бо тоді у вивід можуть потрапляти символи кольору і їх треба теж обробляти. Також треба задавати уявні розміри псевдотермінала, якщо програма враховує його розміри.

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

Також залишу посилання на гарну статтю на цю тему stdio buffering

Дія відкриває код

Відтепер країни, які цікавляться українським досвідом цифровізації, зможуть зрозуміти логіку Дії, імпортувати код і запустити власні державні сервіси. Сподіваюся, що наш досвід допоможе іншим урядам побудувати свої держави в смартфоні.

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

Першим кроком, окрім загального коду серверної й мобільної частини застосунку, ми додали документ Посвідчення водія та послугу Витяг про несудимість як приклади логіки роботи застосунку з даними. Із часом послуг та документів буде більше.

А ще кожен айті-фахівець зможе проаналізувати код і запропонувати, як покращити Дію.

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

Відкритий код — це одна з топових світових практик. За таким підходом робили європейські ковід-сертифікати та Європейський гаманець цифрової ідентифікації, а також так працюють компанії Linux, Android та MySQL.

Ділимося українським діджитал-досвідом і зміцнюємо міжнародний імідж цифрової країни.