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

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

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

26.08.2025

Low Magic vs High Magic

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

Розглянемо маршрутизацію для вебу. В Express.js чи Gin для Go звʼязок між маршрутами та обробниками очевидний - бо ми передаємо їх явно. Звісно, всередині маршрутизатора є багато коду, який ми не знаємо, але головне, що ми бачимо той наш код, який буде виконано. А значить, навіть людина, незнайома з таким фреймворком, зможе прочитати код застосунку та здогадатись, що відбувається.

В протилежність: маршрутизація в Ruby on Rails. Маршрути тут вказують на… щось? Після читання документації можна зрозуміти, як формується назва контролера та його метода, що буде виконано. Але це суцільна магія — нічого в коді на це не вказує. Така саме ситуація в Rails, наприклад, зі структурою моделей (яка взагалі читається прямо з бази наживу.)

Може така магія робить код красивим та зберігає від зайвої писанини. Проте також вона так ускладнює роботу IDE, що досі підказки по коду для Rails потребують спеціалізованого підкажчика, який “розуміє” Rails, а не просто читає код. Та й людям, очевидно, не так легко встрибнути.

Мене колись давно саме ця магія й відштовхнула від Rails - бо з першого погляду застосунок складається з купи неповʼязаних між собою класів. А цілісна картина зʼявляється тільки після читання документації. Після всієї цієї магії застосунок із Gin освіжує своєю прямолінійністю.

25.08.2025

Робота в незвичайних місцях

Ні, я не про роботу наодинці, бо з ноутбуком можна сісти де завгодно, це зрозуміло. Проте памʼятаю я кілька епізодів, де ми разом вилазили з офісу. Та не просто “говорили про роботу за обідом”, а дійсно працювали. Завжди це було гарно: зміна обставин надихає на творчі, сміливі ідеї.

🍃 Одного разу, дуже давно, ми з керівництвом просто вийшли в скверик неподалік, щоб обговорити майбутню архітектуру. Була весна, світило сонце, навколо все зелене. Чому так частіше не робити?

🍸 Другого разу, вже зовсім іншою командою, посеред дня зібралися та пішли до бару планувати проєкт. (Ще я там першого разу скуштував теплі оливки - звучить дивно, але насправді гарна закуска!) Бар - це якийсь особливий настрій для роботи. Навіть просто прийти з ноутбуком раджу спробувати. Тільки краще з чимсь таким, для чого потрібний політ фантазії, а не концентрація.

☕ Є в мене й проєкт, що повністю робився в кавʼярні, і це теж було чудово. Зустрічатися та працювати - завжди було продуктивніше, ніж робити теж саме віддалено.

🌚 А ще памʼятаю, як на офсайті лежали на шезлонгах біля басейну десь до пʼятої ранку та говорили за стратегію. На офсайтах це природніше виходить, звісно, бо люди всі разом. Але можна ж і частіше збиратися та я не знаю, виносити наради з офісу. Або самому виходити. Або - брати людей що вже поруч та з ними разом щось вигадувати?

🏘️ Розумію, зараз складно взагалі зібратися в одному приміщенні. Але коли вдається, не нехтуй тим творчим зарядом, який дає незвичайне місце. Бодай навіть наодинці.

24.08.2025

Надлишок проєктів за браком цілей

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

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

Є проєкти, які очевидно належать цілі: наприклад, “обрати фарби” до цілі “закінчити ремонт”. Для таких проєктів я отримую додаткову мотивацію від розуміння, задля чого воно робиться.

Є такі, де ціль народжується в процесі. Я так знайшов у себе ціль “вибудувати режим” з наче неповʼязаних спочатку проєктів-спроб щось потрохи покращити. Тут наявність цілі відкриває творчий потенціал та можливість вичерпати всі напрямки.

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

Ставити собі цілі не так страшно, якщо прийняти, що вони в тебе вже є - залишилося тільки їх знайти.

23.08.2025

Кілька пакетів для Go, які я ймовірно приніс би у ваш проєкт

sqlc - генератор коду для запитів SQL. Я не прихильник ORM, принаймні на Go, а sqlc робить доступ до бази рівно настільки безпроблемним, наскільки мені потрібно.

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

mockery - а затички я б генерував цим інструментом, з ним мінімум ручної роботи. Менше роботи руками — більше якісних тестів.

testify - не всі використовують його для зручних тестів, та дарма. Тут є assert - зручні перевірки на всі випадки. suite - спрощення для спільного для тестів оточення. Та ті ж mock - для затичок.

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

lo - тут чимало зручних допоміжних функцій, зокрема для дженериків. Прямо все на нього переписувати не варто, але час від часу щось по типу Compact гарно мати під рукою.

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

А у вас є такі пакети, які ходять з проєкту в проєкт, бо просто роблять життя краще?

22.08.2025

Електронні листи із HTML та текстом

Якщо ти пишеш листа власноруч, то, ймовірно, надішлеш його в текстовому форматі. Якщо листа надсилає застосунок — то зазвичай готують HTML. Але широко відомо, що можна також надіслати “подвійний” лист, де буде і те, і те. В мене цими днями була розмова, де ми не знали, для чого так робиться в наш час? Хто ту текстову версію дивиться? Тож вирішив зʼясувати.

(До речі, багато поштових редакторів легко дають форматувати листи та відповідно надсилати HTML. Мій улюблений MailMate навіть підтримує Markdown, та переходить з тексту на HTML, як тільки ти додаєш розмітку.)

Отже. Коли ти готуєш лист у HTML, все одно має сенс підготувати й текстову версію. І не тільки для тих трьох людей, в кого Alpine чи інший клієнт текстового режиму.

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

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

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

Ще окреме питання — як перевіряти подвійні листи, бо у звичайному клієнті ти побачиш тільки одну частину. Можу порадити Mailtrap, бо в нас є зручний перегляд відразу і HTML, і тексту, і коду, і всього чого завгодно.

21.08.2025

Поговоримо про біометрику

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

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

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

(Хоча, ні, є одне поширене “біометричне” рішення, яким ми всі користуємось. Це - CAPTCHA. Зокрема ті CAPTCHA, що проходять неявно, пасивно. Тут дійсно сервер перевіряє зібрані на клієнті показники.

20.08.2025

Passkey - що воно таке є?

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

По-перше, насправді технологія називається Web Authentication, але не дуже це зрозуміло, чи не так?

Технічно Passkey - простіше простого: замість пароля генерується криптографічна пара, публічний ключ надсилається на сервер, приватний — зберігається в безпечне сховище. Для авторизації клієнт підписує приватним ключем пакет-випробування, а сервер — перевіряє підпис. Все це вже знайоме, зокрема схоже працює клієнтська авторизація TLS. (Гарний бік асиметричної криптографії - “it just works”, та не потрібно городити складніших систем.)

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

Складність тут тільки одна — де зберігати оті ключі. Стандарт наполягає на апаратній безпеці — тобто перевірці біометрики або апаратного ключа. Наприклад, в айфоні Passkey зберігаються в Secure Enclave - спеціально виділеному сховищі, доступ до якого відбувається тільки через біометрику.

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

Наприклад, в 1Password цікава історія. З одного боку, ключі від Passkey там зберігаються так само як і будь-який пароль — та раніше ж цього вистачало. А з іншого, для доступу до ключів достатньо знати головний пароль, без всякої біометрики. До того ж ще цікавий момент - 1Password нараді не дозволяє експортувати ключі Passkey - взагалі! Аргументують це відсутністю (поки що) стандарту. Але по факту, Passkey у 1Password привʼязують вас до цього сервісу.

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

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

19.08.2025

Пастка великих змін

“От якби все переписати на Go…” “Треба знайти кращу заміну для Jira” “Цю схему даних робили на колінці, треба спроєктувати хорошу, правильну.”

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

Я зараз не кажу про ті випадки, коли ми дійсно вирішуємо все переробити. Це теж сумнівний хід. Але буває й так, що ми тільки фантазуємо про зміни, щоб можливо потім прийняти справжні рішення.

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

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

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

18.08.2025

Власні атрибути в HTML

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

По-перше, будь-який атрибут повинен починатися з приставки data- Це не просто домовленість, а частина стандарту HTML5. Цікаво, що хто користувався jQuery, той пам’ятає, що data-атрибути використовувалися принаймні за кілька років до виходу стандарту.

В jQuery для них була функція data(), яка спрощувала отримання власних даних, бо всі data-атрибути можна було прочитати однією командою. А на той час вся конфігурація до плагінів робилася саме через розмітку, інколи без жодного рядка власного JavaScript.

Та друге, в HTML немає true та false. Наявність атрибута вважається істиною, відсутність — хибою. Це теж за стандартом. Так що якщо потрібний атрибут, який хибний за замовчуванням — доведеться робити його “негативним”. У нас є гарний приклад зі стандарту - атрибут disabled. Бо enabled="false" було б не за стандартом.

З атрибутами-рядками та атрибутами-числами все традиційніше (ну, хіба що числа все одно мають форму рядків.)

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

17.08.2025

Thief

Згадав вчора про Deus Ex, але мені миліша друга гра того покоління та того ж легендарного розробника Looking Glass Studios.

Це, звісно, Thief. В мене з нею особиста історія. Колись на початку 2000-х потрапив в руки диск, де було ще щось нецікаве та… Thief. Хоч вона й мала погляд від першої особи, але це було щось зовсім особливе. Тут не те що стріляти доводилося нечасто — взагалі, герой дереться не дуже. Та кращий вибір — це завжди ховатися в тінях та тікати від сутичок.

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

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

Є думка, що Thief 2 всім краще за Thief. Візуально та механічно вони майже однакові, зате до Thief 2 команда знайшла свій жанр та гра вийшла більш цілісною. Треба памʼятати, що Thief був першим у своєму роді, та тому містить не тільки маєтки чи тюрми, а й такі рівні, як величезні катакомби та ще більші печери — які були б більше на місці у Tomb Raider. Яка вийшла на два роки пізніше! А для мене ці рівні одні з улюблених. Так що раджу пройти обидві частини. :)

До речі, за керуванням вони цілком сучасні, особливо з патчами. Графіка застаріла, але її естетика збереглася та насторожені охоронці крадуться темними коридорами так само мальовничо. Студії Looking Glass навіть з тими засобами вдалося зробити світ, який відчувається великим без того, щоб виливати на гравця ведра експозиції. Це вічно, як Half-Life (того ж 1998 року!)

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

Раніше