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

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

28.09.2022

SMTP - діалоговий протокол. Шифрування SMTP

✉️📭💬 Продовжуючи серію про дивний протокол SMTP. Який ми всі використовуємо щодня, але ніхто не знає, як він працює.

Як вам така дивина: на відміну від HTTP, SMTP - протокол діалоговий. Тобто для того, щоб відправити одного листа, потрібно обмінятися з отримувачем не однією, а декількома командами. Спочатку HELO, потім MAIL FROM, потім RCPT TO, і нарешті DATA - зміст листа. Перед тим, як слати наступну команду, треба дочекатись відповіді до попередньої. Проблема в тому, що затримка підключення накладається на кожну з команд, тож з повільним звʼязком або на далекий сервер SMTP йде набагато довше, ніж HTTP. Це, до речі, одна з головних причин того, що сьогоденні поштові сервіси як то Mailtrap або SendGrid пропонують відправляти по HTTP API, а не по SMTP.

А ще через цю діалоговість SMTP має дуже дивну форму шифрування. (Бо, звісно, всі листи, як і вебсайти, варто відправляти тільки через зашифрований канал.) Так от, хоч і існує SMTP-аналог до HTTPS, тобто, коли спочатку встановлюється канал TLS, а потім вже через нього SMTP, але такий спосіб непопулярний. Натомість у протоколі SMTP є команда STARTTLS, після якої сервер має припинити комунікацію по відкритому каналу, та почати сеанс TLS на тому самому підключенні. І так роблять практично всі клієнти SMTP. Через STARTTLS всім серверам SMTP доводиться керувати власними TLS-сертифікатами, і не можна цю роботу делегувати балансиру, як це зазвичай трапляється з HTTP.

27.09.2022

DKIM - механізм підпису листів SMTP

🔐✉️✍️ Сьогодні розкажу про DKIM - один з механізмів безпеки поштового протоколу SMTP.

SMTP - унікально лібертаріанська система. Як і в реальному світі, до вашої поштової скрині може покласти будь-хто та будь-що. Хто завгодно в інтернеті може надіслати листа з будь-яким змістом. Немає ніяких механізмів авторизації. Це, мабуть, підходило для інтернету в 80-х, але в наші часи це й дозволяє існування спаму. З усім тим, SMTP, як найвитриваліша і найпоширеніша система комунікації, продовжує існувати та нема основ вважати, що колись перестане.

Так от, за відсутністю авторизації, SMTP працює за принципом довіри. Кожен лист оцінюється на автентичність. Вплинути може і зміст листа, і сервер відправника, і багато різних факторів, які цілком не оголошуються. (Бо попри всю відкритість, більшість скринь в інтернеті належать до GMail, а за ним — до декількох провайдерів менше. Кожен має свій ноу-хау для визначення спаму.)

DKIM - це один з погоджених механізмів, що покращить автентичність вашого листа. Якщо дуже просто, то це електронний підпис. Лист підписується деяким доменом. Такий підпис можна зробити тільки з дозволу власника домену. В першу чергу накладається підпис домену відправника (як вказаний в адресі), але також може бути домен сервера, що виконує виправляння. А взагалі технічно лист можна підписати будь-яким доменом, тільки навряд чи це вплине на автентичність.

DKIM працює за звичним принципом криптографічної пари. Приватний ключ знає тільки відправник і використовує для підпису змісту листа. Публічний ключ оголошують в особливому DNS-запису. Тоді будь-який отримувач може дістати публічний ключ та перевірити підпис.

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

Щоб подивитись підпис DKIM листа в вашій поштовій скрині, дивіться на заголовки DKIM-Signature, а також Authentication-Results (його додає ваш поштовий сервіс.)

26.09.2022

Ключові моменти розробки схеми для AWS Redshift

❄️📦🪣 Сьогодні вдало попрацював з AWS Redshift.

Redshift - це аналітична (OLAP) база даних, що виросла з PostgreSQL, виглядає як PostgreSQL, але працює фундаментально по-іншому. Вона призначена для обробки великого обсягу даних, про що свідчить і цінник, що починається з $0.25 на годину.

Але просто завантажити дані у Redshift та отримати швидкий результат не вийде. (Перевірено.) Треба знати деякі ключові моменти.

Спочатку треба зрозуміти, що це не база для транзакційного використання — робота з індивідуальними записами набагато повільніша, ніж у Postgres.
Redshift, як стовпчикова база даних, добре робить внутрішню “нормалізацію” даних, тому від явної нормалізації не так багато вигоди.
Індексів у Redshift взагалі немає. Замість індексів є ключ сортування та ключ розподілення. Від правильно заданих ключів продуктивність запитів може різнитися на порядки.
Ключ розподілення (distribution key) - це колонка, яка визначає, на який вузол потрапить рядок. (Бо на відміну від Postgres, Redshift відразу розподіляє рядки таблиці по всіх вузлах у кластері.) Такій колонці варто мати рівномірно поділені значення, для досягнення найбільшої вигоди від паралелізації.
Ключ сортування (sort key) - це колонка або декілька, що задають фізичний порядок зберігання даних. Це значно впливає на швидкість фільтрації по ключу, а також операції JOIN. Якщо, наприклад, дані поділені по клієнтах, то сортування по коду клієнта дозволить Redshift просто відкидати при обробці всі дані, окрім даних вказаного клієнта.
Матеріалізовані розрізи (materialized view) у Redshift категорично крутіші, ніж у Postgres, і їх опанування є критично важливим для розкриття можливостей цієї бази.
Перше - materialized view можна оновлювати не тільки цілком, але й інкрементально — що набагато швидше, особливо зі складними запитами. Є певні інтуїтивні обмеження на запити, які це підтримують. Наприклад, максимум можна порахувати інкрементально, а кількість унікальних значень — ні.
Друге - materialized view можна оновлювати автоматично — тобто Redshift сам відстежує зміни у вхідних таблицях, та оновлює розріз (навіть інкрементально). На жаль, це не працює з каскадами розрізів. Емпірично, оновлення відбуваються протягом хвилин.
Для розрізів так само задаються ключі сортування і розподілення, тобто це повноцінні та повно-швидкісні таблиці.
А ще Redshift вміє і забирати дані з AWS S3, і отримувати їх з Kinesis Firehose.

25.09.2022

Оновлення гему Liqpay

💳💸💎 Сьогодні несподівано випустив оновлення гему Liqpay для Ruby on Rails.

Цей гем я зробив одинадцять років тому, щоб уможливити оплату на одному проєкті. Тоді екосистема онлайн-платежів була зовсім іншою аніж зараз. Втім, LiqPAY все ще живий та здоровий, та використовується багатьма українськими сервісами. Тож гем все ще може комусь згодиться. Він додає до Ruby on Rails хелпер кнопки оплати, що перекине покупця на LiqPAY, а потім відправить результат на адресу вашого сервера. Таким чином, за кілька годин ви вже будете приймати оплати з українських користувачів.

В LiqPAY за ці роки небагато змінилось. Що головне, то вони переїхали на новий хост, а старий повністю відключений. (Зворотна сумісність 0 з 10.) Актуалізація адреси API й була головною метою оновлення. Крім того, освіжив код:

додав та виправив Rubocop
додав тестування через GitHub Actions - бо вони безплатні для публічних репозиторіїв, дуже зручно.

І нарешті, тестовий додаток був на третій рельсі. Звісно що довелося оновити до сьомої. Тут я згенерував новий додаток, а потів скопіював ті декілька файлів, що реалізують оплату.

До речі, з ПриватБанком я ніяк не повʼязаний і вони мені нічого за це не платять. (Тому, може, я й не оновлюю бібліотеку аж 4 роки після того, як перестав працювати старий URL.)

24.09.2022

Підходи до локализації блогу на Hugo

🌐📖🔄 В мене на блозі триває SEO-покаліпсіс: майже всі сторінки випали з індексів, та відвідувачі з пошуковиків практично скінчились. Зробив деякі зміни, щоб виправити, але на жаль пройдуть дні, поки я зможу побачити якийсь результат.

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

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

(До речі, Hugo буде додавати до всіх адрес локалізованих сторінок префікс з кодом мови. Цього неможливо уникнути глобально, але для конкретної сторінки завжди можна задати повний url у front matter - тоді префікс не додається.)

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

Тому натомість просто додав свій, особливий параметр сторінки lang (насправді він давно вже був), і використовую його для локалізації окремих сторінок (наприклад, у тезі <html lang="uk">). Ще бачив поради зробити мову тегом або категорією. В будь-якому разі, тоді Hugo продовжує працювати у звичайному режимі без локалізації.

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

23.09.2022

TLS сертифікати, де їх взяти, та проблеми з ними

🌎🔐💸 Продовжуючи тему проблемних вебтехнологій: TLS. Або ж SSL (чи знаєте ви, що TLS - це нова версія SSL, а SSL абсолютно застарілий та ненадійний та давно його ніхто не підтримує?)

Зараз такий час що всі користуються TLS, а все завдяки поширенню чудової ініціативи Let’s Encrypt. Тепер будь-хто може безплатно отримати сертифікат для сайту. Тепер і більшість хостингів безплатно створять його за вас, включаючи й AWS. Це дуже добре, що всі мають доступ до безпечного інтернету.

Де ж проблеми? Проблеми в тому, що не всюди ці сертифікати приймають. Якщо сертифікат вам потрібен для сайту на HTTPS - то, напевно, обійдетесь Let’s Encrypt. (Чи знаєте ви, що HTTPS - це звичайний HTTP, але комунікація відбувається через канал TLS?) Браузери з ними нормально працюють — і браузерів насправді не так багато.

Але якщо сертифікат потрібен не для сайту — наприклад, для API, або для зовсім іншого протоколу, може, SMTP або бази — то можете готуватись до того, що хтось з клієнтів матиме проблему з його перевіркою. Та й з браузерами, уявіть себе, у нас був випадок, де сертифікат AWS не приймався у деяких користувачів. Пояснювати покупцям, що вони мають оновити системні сертифікати, або ще якось виправляти на свому боці, діло невдячне.

Тому, якщо у вашого проєкту є бюджет хоч на $20 на рік, раджу придбати “справжній” сертифікат і не мати проблем. Справжній — то від серйозного емітента, наприклад, Comodo. Рекомендую купувати на NameCheap, хоч вони мені не платять. До того ж оновляти такий сертифікат доведеться раз на рік, а не на місяць.

22.09.2022

Чому я раджу не тримати свій DNS сервер

🕸️📖👈 Що я вам скажу — не раджу підіймати свій DNS.

Принаймні, не рекурсивний. Річ у тім, що DNS - вкрай езотерична технологія. І хоч ми всі їй користуємося постійно, мабуть, мало хто здогадується, що таке рекурсивний DNS, і який ще буває.

Так от, DNS це насправді дві роздільні системи.

Перша — це, грубо кажучи, дерево DNS-серверів, які зберігають адреси сайтів. А саме, є кореневі сервера, що знають адреси DNS-серверів доменів верхнього рівня (.org). Далі у домену .org є свої сервери, які знають адреси DNS-серверів всіх доменів .org - наприклад, .telegram.org. Зазвичай DNS-сервер домену другого рівня скаже вам адресу самого сайту та його піддоменів. Але не завжди — бо глибина дерева технічно не обмежена. (До речі, самі DNS-сервера вказуються у вигляді доменів, а не IP-адрес. Мені це здається зациклюванням, але ж якось воно працює. Таємниця!)

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

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

А є ще публічні кешуючі DNS сервери, наприклад, 1.1.1.1 від Cloudflare. Їх користь в тому, що вони працюють “нормально”. Бо протокол DNS складний і неоднозначний, і в деяких історичних ситуаціях “нормальні” сервери роблять не так, як написано. (Принаймні, це я так розумію.)

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

Якщо хочеться почитати про DNS більше, раджу чудовий блог Джулії Еванс.

21.09.2022

Моя боротьба з пошуковою оптимізацію та поради

🔎🧰🔥 Сьогодні боровся з пошуковою оптимізацією.

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

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

Отже, раджу зареєструватись у Google Webmaster Tools, а також в Bing Webmaster Tools, і подивитись, що вони кажуть. Лайфхак: підтверджені сайти з Google можна в один клац імпортувати до Bing. Тобто не треба два рази підтверджувати власність.

І не зволікайте на те, що Bing не такий крутий, як Google. Бо саме в індекс Bing дивиться DuckDuckGo, а ось DDG досить популярна альтернатива Google. Та й сам Bing у багатьох користувачів Windows стоїть за замовчуванням.

Що я сьогодні встиг зробити, це додати до всіх сторінок meta description. Бо Bing їх дуже хоче. А також виправити внутрішні посилання, що вели на сторінки без кінцевого слешу. Бо як виявляється, Google не може з цим змиритися, навіть якщо посилання насправді працюють через перенаправлення. А ще додати до сторінок тег link rel=canonical, що допомагає пошукачам зрозуміти, яку саме сторінку показувати — це теж корисно у ситуації з перенаправленнями.

До речі, для вебаналітики я вже більше як рік користуюсь Plausible. Це платний сервіс, який свідомо не будує ніякого “портрету користувача”, а спирається тільки на анонімну статистику.

20.09.2022

Прибирання диску автоматичними засобами - Hazel та інше

📁🧹🗑️ Як впоратись з програмами, які невпинно створюють на диску всякий брухт? Як приклад: XCode накопичує архіви з кожної збірки, а також файли підтримки для кожної нової версії iOS.

Для автоматичного управління файлами для macOS існує додаток Hazel. Він вміє не тільки видаляти файли, але й впорядковувати за різними схемами. Ідея така: Hazel слідкує за директоріями. Задаєш шлях до директорій та правила вибору та обробки файлів; якщо є такий файл — то зробити таку дію. Наприклад, можна слідкувати за директорією з архівами XCode та видаляти все, що старіше за місяць.

Ще зручно за допомогою Hazel виправляти незручності в автоматичному розміщенні файлів. Наприклад, я не люблю, коли програми зберігають файли на робочий стіл. Тож можна зробити так, щоб Hazel переносив всі файли з робочого столу в документи.

Що Hazel погано вміє робити, це слідкувати за глибоким деревом директорій. Технічно така можливість є — через правило recurse into directories - але воно дуже неефективне.

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

А ще щоб знайти, куди ділось місце, багато років використовую DaisyDisk. Можу і для Windows порадити - TreeSize.

19.09.2022

Пара порад про налаштування GitHub Actions

😸🔐⚙️ Пара порад про налаштування GitHub Actions.

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

Провайдером навіть можна записувати файли, тобто поширювати між репозиторіями налаштування лінтерів та інші файли, що неможливо винести в залежності.

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

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

Взагалі GitHub Actions це може не найпотужніше система безперервної інтеграції, але перемагають через глибокі звʼязки з GitHub - починаючи з того, що доступні в його інтерфейсі та не потребують додаткового керування доступом. Якщо у вас є ідеї, чому може бути варто не брати GitHub Actions, а піти до конкурентів, буду радий дізнатись.

Раніше

Пізніше