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

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

05.04.2025

Чи потрібний SQL, якщо є ORM?

Потрапила на очі фраза “хто ж пише SQL, коли вже н-цять років існують ORM?” Хотілося прокоментувати. Тут є цікавий розподіл.

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

Наразі існує достатньо нереляційних баз, щоб побачити, що ця можливість не є універсальною. От в OpenSearch все, що ми можемо — це шукати документи за критеріями та агрегувати. Все інше — дорого (та реалізується тим самим пошуком.) У CoreData немає COUNT. В DynamoDB взагалі кожний запит треба задумати наперед.

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

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

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

04.04.2025

Прискорення тестів на CI

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

Неприємність тут в тому, що не вийде прискорити тести простим киданням грошей на більші машини. Вигода від того буде обмежена. (Хоча якщо тестам не вистачає, скажімо, памʼяті, то збільшення машини точно буде вартим.)

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

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

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

Але зрештою, якщо налаштувати split_tests в режимі JUnit, то виходить дуже непогано! Рекомендую.

03.04.2025

Як я писав екзамени

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

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

Дуже часто узагальнення працюють достатньо гарно, особливо якщо мати справу з синтетичною вибіркою. В шкільній програмі з історії всі події “визначні” чи “вирішальні”, в літературі всі персонажі “яскраві”, а твори “повчальні”. Тож і про конкретну подію чи персонажа можна щось красиве вигадати. 🖋️

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

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

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

02.04.2025

Docker та стан у файлах

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

Як яскравий приклад: в Docker недоцільно запускати базу даних. Якщо воно у вас локально та не страшно все зупинити та запустити наново — то най буде. Але в живому використанні, а то ще й на хмарному сервісі чи в Kubernetes - відразу виявиться проблемка: директорії зі станом зазвичай не розраховані на одночасне використання двома копіями сервісу. В кращому випадку отримаємо помилку на кшталт “сервіс вже запущений”, а в гіршому — вони тихо потроху псуватимуть стан.

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

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

01.04.2025

Гіпермедійні застосунки проти SPA

Переглянув тут книжку Hypermedia Systems, яку порадив автор дружнього каналу. Тезою книжки є те, що індустрія у любові до JavaScript втратила простіший, кращий підхід до розробки застосунків, де сервер займається промальовкою HTML, а клієнт вміє надсилати команди сервера згідно з семантичною розміткою. (А краще самі почитайте, бо одним реченням не передати.)

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

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

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

Але головною проблемою offline first є навіть не складність, як я писав раніше, а гроші. Бо великі гроші заробляються на корпоративних клієнтах, які потребують співпраці над даними. (До того ж в застосунках “для простих людей” гроші робляться на використанні даних… що легше зробити, коли вони на сервері.)

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

31.03.2025

Очікування в інтеграційних тестах

Хто що використовує для фіча-тестів? Я вже бозна скільки років на Capybara, та про інші фреймворки знаю тільки поверхнево. Але це показник того, що Capybara така хороша, що для Ruby on Rails нічого більше не потрібно.

Але гадаю, тема сьогодні незалежна від інструмента. Фіча-тести ніколи не є на 100% стабільними. Графічний інтерфейс це вже складно, а коли його автоматизувати, то складність тільки помножується. Тому багато фіча-тестів дають хибу, але не кожного разу — а випадково.

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

Але то якщо правильно писати тести. Наприклад, Capybara чекатиме тільки всередині перевірок. Якщо просто звертатися до елементів, то невідомо, чого саме чекати. Ще є класична помилка expect(page).not_to have_content: тут Capybara не знає, що потрібно чекати, поки зміст зникне. Правильна форма - expect(page).to have_no_content.

До того ж очікування не розвʼязують питання послідовності дій. От виправляв тільки-но помилку, де сценарій інколи стартував ще до того, як компонент React встигне перемалюватися з даними. В такому разі перший крок сценарію затирався. Я собі стільки морочив голову над поведінкою та можливими проблемами з кнопкою SVG, а виявилося, що лише треба було на початку почекати правильного стану.

30.03.2025

Вимикач замість пультика

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

Раніше з цією люстрою просто була класична проблема, що вимикач на стіні вимикав її повністю, разом із вентилятором. Але після ремонту той фізичний вимикач приховали (та залишили, як резервний.) Тепер проблема інша: пульти я просто не переношу — тому керування було перенесено в розумний будинок.

Для того в мене є інфрачервоний прожектор Broadlink Universal Remote - я вже раз, два, третю роботу для нього знаходжу. Він є окремим пристроєм з живленням по USB, тому таких прожекторів можна розставити по кімнатах там, де це потрібно.

В базовому вигляді Broadlink надає можливість вивчити та надсилати команди по ІЧ. А якщо йдеться про вимикачі, то в інтеграції Broadlink для того є окремий режим вимикача. Там з двох команд утворюється сутність (entity) вимикача, для якої HA памʼятатиме стан та дозволить використати в автоматизаціях операцію “перемкнути”.

Нарешті, залишається ту операцію привʼязати до натискання вчорашньої Shely BLU Button, та фізичний вимикач готовий! Один — на світло, один — на вентилятор. 🌪️

29.03.2025

Вимикачі через HomeAssistant

В мене трохи відбувається ремонт, частиною якою — волею чи неволею — є впровадження розумного будинку. Чесно, я прибічник простих рішень та фізичних перемикачів, але інколи “просто” не виходить.

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

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

До реле достатньо підвести 220, хоча можна й фізичний вимикач. Решту воно робить через Wi-Fi. Те ж саме реле можна взагалі сховати у звичайній коробці будь-якого вимикача, та зробити його розумним, тобто додати можливість вмикати та вимикати віддалено. Проте в мене як раз вимикача й бракувало.

Shelly чудово інтегрується із HomeAssistant. Але вимикач потрібний фізичний. З цим в мене досвіду поки не було, тому взяв від тих же Shelly BLU Button. Набув досвіду: кнопка трохи повільна, на мій погляд, через те що вона на Bluetooth. (Зате менше жере енергії?) До речі: то ж саме реле виявилося здатним виступати як приймач Bluetooth, абсолютно несподівано, бо я збирався підʼєднувати до HA адаптер.

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

Приклад 2… вже сьогодні не влізе. :)

28.03.2025

Почитай книгу

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

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

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

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

Наведу пару прикладів. Колись мені дуже допоміг The DynamoDB Book - треба було зрозуміти, що ж воно таке то DynamoDB, та як на ньому збудувати архітектуру. Бо основи легко знайти в посібниках, але що з ними далі робити?

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

Отже. Хочеш підвищити рівень — знайди почитати гарну фахову книгу.

27.03.2025

Чим складні SPF, DKIM, та DMARC?

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

SPF - це DNS (TXT) запис, що оголошує, з яких IP-адрес дозволено надсилати пошту від вашого домену. Складність 1: йдеться про Envelope FROM, то треба знати, що це таке. Та не забути налаштувати поштову програму, щоб вона використовувала правильний. А також, оскільки SPF оголошує айпішки, то треба, щоб поштова програма виконувалася на машині зі статичною айпішкою, а не десь в хмарі. Та, потрібно не забувати оновлювати той запис, коли адреси змінюються (та вміти його правильно скласти.)

DKIM - про який я вже розповідав - це асиметричний підпис листів. Публічний ключ сидить в TXT записі до вашого домену (А тут вже можна і домен Envelope FROM, і просто From:, а краще — обидва!) А приватним потрібно підписувати важливі заголовки в кожному листі. Мені особисто підпис заголовків це завжди головний біль, бо їх треба зібрати, нормалізувати, скласти до купи… Звісно, на то є бібліотеки, головне — інтегрувати їх у поштову програму.

DMARC - а оце дійсно просто. DMARC тільки оголошує про наш намір використати SPF та DKIM. Бо, бачите, без DMARC незрозуміло, чи вважати відсутність механізму сильним відʼємним сигналом. Але наявність DMARC (який стає зараз примусовим для листів на GMail та Yahoo) збільшує наслідки від поламки SPF/DKIM.

Але все ж головною проблемою є те, що всі ці механізми тільки підтверджують автентичність домену відправника. А те, що цей домен не bank.com, а bank.com.abcdef.xyz - їм всім абсолютно байдуже.

Раніше

Пізніше