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

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

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 - їм всім абсолютно байдуже.

26.03.2025

Шифрування на кожний день: AEAD

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

Тому ділюся головним скороченням, яке треба знати: AEAD. Якщо вам потрібно “щось зашифрувати”, то оце воно. AEAD попросту значить, що окрім зашифрованого повідомлення, передається також і його підпис — за яким можна підтвердити, що дані не сфальсифіковані. (Цікавий факт: будь-які двійкові дані можна “розшифрувати” за алгоритмом та отримати якийсь відкритий текст. Так що підпис рятує не тільки від фальсифікації, а й просто втрати інформації.)

Але насправді навіть не потрібно знати, що там є підпис, бо його за вас зробить (та перевірить) бібліотека шифрування. (Правило шифрування №1 - не пиши нічого сам!) А от що від нас залежить, так це вибір нонса, який повинен бути унікальним в межах одного ключа. Якщо ви не плануєте одним ключем шифрувати мільярди посилок, то звичайний випадковий нонс влаштує.

Щодо конкретних алгоритмів, то є 2. Золота класика: AES256-GCM. Оптимізований на апаратному рівні, використовується у Wi-Fi, TLS, та багато де ще. Та новий модний ChaCha20-Poly1305 - більш безпечний (як каже інтернет), швидший на ARM, теж використовується у TLS, WireGuard тощо. Обидва алгоритми вас влаштують.

У JWE - це який JWT, але зашифрований — теж, до речі, AEAD.

25.03.2025

Підтримка relref для Mastodon

Приблизно два роки в мене в ПЗ для каналу є спосіб вказати посилання так, щоб на сайті воно вело на сайт, а в каналі Telegram - на пост в каналі. Сьогодні доробив цей функціонал й для публікації в Mastodon.

До речі. Mastodon досі не вміє публікувати Markdown. Тому технічно, наразі я підтримую не Mastodon, а GoToSocial, та, здається, ще Akkoma. Але — я використовую API Mastodon, звідси й назва.

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

Мені такий підхід згодиться й в майбутньому, бо він допоможе позбавитись від тих конструкцій, які підтримуються неповноцінно.

24.03.2025

Чому спамери краще вміють в SMTP?

Я тут багато писав про особливості SMTP (бо саме з ним пощастило працювати останніми роками на Mailtrap.) Натрапив тут на пост, де згадувалося, що спамери краще виконують (так, виконують, а не обходять) механізми захисту SMTP, ніж легітимні відправники. Хотілося прокоментувати.

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

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

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

23.03.2025

Редагування статусів у Mastodon та інше

Інкрементальні покращення для OmniWope:

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

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

Пощастило, що поки я збирався публікувати в Федиверс, в GoToSocial - мого сервера — зʼявилася можливість редагування. Тож сьогодні додав потрібний виклик та все запрацювало. Цікаво, що в ActivityPub редагування статусів є федерованою операцією, тобто не можна бути впевненим, що воно доїде до кожного отримувача.

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

22.03.2025

Стендап Сьогодні — тепер і в Федиверсі

Нарешті я на це наважився та публікую цей пост на @stendap_sogodni@shevtsov.me. Перфекціонізм мене тут зупиняв вже надто довго, треба з чогось почати. Запрошую підписатися!

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

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

З проблемами HTML я поки нічого не робив, оскільки… треба з чогось почати. Поки зрозумів, що процес такий: мій сервер робить з Markdown HTML, а потім цей HTML вже обрізається клієнтами. Тож мені доведеться підбирати такий Markdown, який буде перетворений у прийнятний HTML. Тобто це ще окрема непроста задача.

21.03.2025

Музика для роботи

🎧 Давайте таку пʼятничну тему: що слухати під час роботи? В тиші сидіти гарно, коли настрій закопатися у роботу. Але для не таких гіперцікавих справ доводиться щось увімкнути.

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

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

♥️ jungletrain.net - це мій поточний фаворит. Музика 24/7 без передач та реклами. Джангл для мене як раз ідеальний баланс між фоновим та цікавим, та — що важливо — стабільний правильний BPM.

@ThePrimeThanatos на YouTube - тут 24/7 синтвейв. Я взагалі люблю синт-всяке, але це трохи не мій робочий темп.

Ще багато плейлистів в Apple Music є хороших. Jazz Soul Cafe та [Piano Bar](http s://music.apple.com/ua/playlist/piano-bar/pl.fc0d9d21c13c46149110dfd8dd844896) часто вмикаю.

🎶 А ви що слухаєте за роботою?

20.03.2025

Федиверс та децентралізовані соціальні мережі

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

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

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

Головною перевагою Федиверсу є воля. Тут немає “алгоритмів”. Хоча може на якомусь сервісі є, але ми самі повинні його обрати. Так само модерація є локальним явищем. “Алгоритми” та модерація корисні речі, але не тоді, коли ними керує велетенська безконтрольна корпорація. Тому, я гадаю, Федиверс, з локальними спільнотами, звичаями та законами, ближче до “мрії Інтернету”, ніж то темне місце, в якому ми зараз опинились.

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

Раніше

Пізніше