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

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

04.10.2022

Нюанси міграції на TypeScript

☕🪟✨ Сьогодні довелося відповісти на пару питань про міграцію на TypeScript.

До своєї статті про перехід на TypeScript можу додати ще пару пунктів.

TypeScript - це все ж таки не “JavaScript з типами”, а мова, що семантично відрізняється. На TypeScript є власні ідіоми, які в JavaScript не поширені. Тобто при переході доведеться навчитися писати код по-іншому. Бо, з протилежного боку, деякий ідіоматичний код JS погано типізується і буде псувати все враження від TypeScript. А ще це значить, що деякий код набагато простіше переписати, ніж покрити типами.
Наприклад: випадки з невизначеним життєвим циклом змінних (або властивостей обʼєкта.) В JS ми просто приймаємо на віру, що присвоєння значення відбувається до його використання. TS з таким не погодиться, і вимагатиме, щоб при кожному звертанні до змінної ми перевіряли, чи вона має значення. Тут доцільно вжити discriminated union чи ізолювати змінні по меншім функціям.
JS побудований навколо парадигми “аби працювало, щоб ти не написав”. Звідси походять всі WAT та інше. В TS навпаки, тип завжди відомий, тому не потрібно стільки вгадувати значення та захищатись від несподіванок. Як плата за це, потрібно робити перевірки на коректність коду, які в JS здаються непотрібними - наприклад, про наявність індексу в масиві чи обʼєкті. Треба розуміти, що це і є цінність і мета використання TypeScript, і перевірки дозволяють уникнути помилок в крайових випадках, коли вони трапляться.
З чого почати типізацію? Моя порада — почніть з найпростіших типів. Зазвичай це значить почати з моделі та з маленьких функцій. Ще можна досить легко перекласти prop types для React до типів. До речі, потім prop types можна викинути.
Якщо десь не вдається розкласти по типах — то може бути й таке, що пора переписувати. А для цього краще мати добрі тести.
Не соромтеся оголошувати прості маленькі типи замість копіпасти, якщо декілька функцій чи компонент працюють з однаковими конструкціями.

03.10.2022

Клієнти для баз PostgreSQL - pgcli та SQLTools для VSCode

🗄️☁️🧰 Поділюся парою інструментів для доступу до баз даних SQL. (В мене це завжди Postgres, але інструменти універсальні.)

(Цікаво, що раніше якось завжди був поруч якийсь графічний клієнт — наприклад, phpMyAdmin, — а зараз немає ані в мене, ані у колег не бачу. Можливо, це результат того, що в Ruby on Rails зручніше писати запити в консолі на мові Ruby, це одна з величезних переваг RoR. Втім, інколи доводиться писати й чистий SQL. Для цього маю улюблені програми.)

pgcli - це просунутий клієнт PostgreSQL для командного рядка. Наприклад, там є підсвітка синтаксису, автодоповнення, і зручний показ результатів. А ще її можна запустити з URL бази даних замість купи параметрів. Працює також і з Redshift. Є варіанти й для інших баз даних. Я їм вже багато років користуюсь, тому вже забув, що там psql вміє робити.

Нещодавно ще почав вживати доповнення SQLTools для Visual Studio Code. Хотів, щоб був короткий цикл розробки: відредагував запит — запустив — подивився результати. І дійсно, це у SQLTools виходить чудово: редактор і результат запита ділять вікно навпіл. При цьому можна запускати як весь зміст файлу .SQL, так і один поточний запит, що взагалі дуже зручно. А ще SQLTools автоматично форматує скрипти, робить автодоповнення. Результати можна експортувати у CSV або JSON. Все це не виходячи з IDE та без копіювання запитів в інший додаток.

Так що зараз в мене вибір такий: для разових задач - pgcli, для розробки - SQLTools.

02.10.2022

Чуйка на проблеми - найважливіша якість інженера

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

Що я маю на увазі. В нормальному стані людина приймає найочевидніші рішення, рухаючись несвідомо від ситуації до ситуації. Бо думати — це тяжко (без жартів.) І так відбувається не тільки з механічними діями. Можна несвідомо розвʼязувати досить складні інтелектуальні задачі, якщо ланцюг “очевидних” рішень виведе до розвʼязку (наприклад, відеоігри на цьому побудовані — бо там завжди є розвʼязок і шлях до нього.)

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

Так от, ця моя “чуйка на проблеми” це здатність помітити, зупиниться і подумати. Оце головна риса інженера. Чуйку треба розвивати, щоб вона була як рефлекс. Бо вона нас має витягати с несвідомого автоматизму.

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

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

…Ось ще сьогоденний приклад. Хотів купити дещо в Nintendo eShop. В Україні він взагалі не працює, тому в мене встановлений регіон США. А в ньому несподівано перестали працювати українські картки. Поспішав, перепробував вже купу карток і способів (PayPal, напряму, через поповнення кишені) - не хоче. А гугл моментально підказав, що треба було переїхати в Польщу, і картка Монобанку спрацювала без проблем. Треба було просто зупинитись і загуглити.

01.10.2022

Fly.io - зручна платформа для невеликих проєктів на Docker

☁️🏗️🎈 Хотів написати довший пост сьогодні про те, як заощадити гроші на хостингу, але виявилось, що економія доступна тільки в планах з місячною підпискою, тож пост буде коротше.

Мова йде про Fly.io. Це мій улюблений хостинг для проєктів-хоббі. Можна сказати, новітня заміна Heroku (а оскільки Heroku закрив безплатні плани — то саме час знайти їм заміну.) Але в Fly.io розміщають контейнери Docker. В наш час це найкращий спосіб розмістити свій додаток в інтернеті: він балансує добрий контроль над змістом і середовищем додатка, та простий і стандартний зовнішній інтерфейс. Будь то Rails, Golang або чийсь сторонній додаток — загорнути їх в Docker не ставить проблем.

Але вибір хостингу для Docker не такий великий. Є Heroku. Є, звісно, всі хмарні платформи — я дуже люблю AWS Fargate, але для малих проєктів це надто дорого і складно. Ще можна завжди підняти свій хостинг на будь-якому VPS, але тоді втрачається вся простота рішення.

На Fly.io місячна ціна починається з $1.94 (і до того поки що ще є безплатний ресурс.) При тому є всі сучасні зручності — метрики, CLI, власні домени з TLS, купа регіонів та інше. В мене вже пару років тут працює декілька додатків - RSS-читач та RSS-адаптер, система коментування для блогу, база CouchDB. Проблем не маю.

Як щодо згаданої вище економії: нещодавно Fly.io запровадили можливість вимикати додатки, коли в них немає клієнтів. Для малих проєктів це було б ідеально. Але, здається, такий функціонал доступний в платних планах від $29 на місяць.

30.09.2022

Дві різні адреси електронного листа

✉️✍️📭 Наступна дивина SMTP. Всі знають, що у листа є адреси “кому” та “від кого”. Але насправді у кожного листа є 2 пари адрес. Якщо проводити аналогію з паперовим листом, то одна пара — на конверті, а інша — на самому листі.

Технічно це виглядає так: електронний лист являє собою повідомлення формату RFC 5322, який дуже схожий на формат HTTP. Між іншим, в листі є заголовки, серед яких і From, і To. Тут все достатньо зрозуміло.

Але називати цей формат “форматом SMTP” буде невірно. Бо, як я вже казав, SMTP - діалоговий протокол, і весь лист, з усіма заголовками відправляється командою DATA. Так от що виявляється — перед цією командою сервер SMTP очікує команди MAIL FROM та RCPT TO, в яких також вказується відправник і отримувач! Це і є той самий “конверт” SMTP, визначений у RFC 5321.

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

Який в цьому сенс? Я напевно не знаю, але знаю одну функцію пошти, яка на цьому базується, а саме BCC - “прихована копія”. (Я це несподівано дізнався, коли довелося її реалізовувати.) Коли ти вказуєш заголовок Bcc, то твій поштовий клієнт відправить лист без цього заголовку, але додасть отримувача в перелік RCPT TO. Так всі адресати побачать той самий лист, але не побачать, хто отримав приховану копію.

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

29.09.2022

Який сенс у тайм-трекінгу?

⏰📝💸 Багато хто не любить тайм-трекінг і бачить в ньому тільки інструмент бюрократії та терору. Я теж не люблю їм займатись, але це як чистка зубів — на тайм-трекінг є користь.

Якщо ти працюєш за гроші, то звіт про час потрібен як артефакт, який приблизно дублює виконану тобою роботу. (Принаймні без роботи звіт складно написати.) Тому замовник може по наявності звіту бачити, що робота робилась. Тут справа не в довірі, а в простих ділових відносинах. Бо всі ж розуміють що результат роботи він може і не побачити, тим паче оцінити. При цьому не стільки важлива точність записів (у сенсі часу), скільки їх кількість та детальність (у сенсі виконаних дій).
Звіт дозволить побачити розподіл уваги по проєктах, якщо їх декілька. Або скільки часу уходить на підтримку та багфікси — дуже важливий показник. А ще прикольно рахувати проєкти-хоббі або просто ті, на які нечасто витрачаєш час. Так, на розбудову Сінтри з мого боку витрачено близько 600 годин.
Звіт вимагає бути усвідомленим і думати про те, чим ти власне займаєшся. Цього нам всім не вистачає. Раджу робити звіт для себе, а не для когось. Чом би йому не бути також інженерним журналом?

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

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

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.)

Раніше

Пізніше