Стендап Сьогодні
Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті
Підписатись на RSS · 📢 Канал в Telegram @stendap_sogodni
- ActiveRecord
- API
- AWS
- AWSLambda
- CGO
- Chezmoi
- CI
- Cloudflare
- CloudflarePages
- CssParser
- CтохастичнийТаймтрекер
- Docker
- Dotfiles
- Fly.io
- GitHub
- Go
- GTD
- Hugo
- JavaScript
- JSON
- Kafka
- MacOS
- Mastodon
- Obsidian
- ObsidianCanvas
- OmniWope
- OpenSearch
- Oura
- Ping
- Plausible
- Redis
- RSS
- Ruby
- RubyOnRails
- SMTP
- SQL
- SQLite
- Svelte
- Swift
- SwiftData
- SwiftUI
- TLS
- Vercel
- VPN
- WeightPlot
- WordPress
- Адвент2024
- Безпека
- Вебтехнології
- ВолюІнформації
- Гаджети
- ДизайнМовПрограмування
- Ігри
- Інструменти
- КеруваннняЗадачами
- Локалізація
- Маркетинг
- МетаПост
- Оптимізація
- ОсновиІнтернетБезпеки
- Продуктивність
- Проєкти
- Проза
- Рівночасність
- РобочийКомп
- Розробка
- СинПопросивПриготувати
- СтохастичнийТаймтрекер
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-х, знає, що колись ніякої централізації не було — головним місцем спілкування були форуми, яких було безліч. На кожному форумі користувачі були свої, тобто мої обліковки на студентському форумі, форумі улюбленої групи, та форумі по розробці ігор були ніяк не повʼязані. Та наче це було навіть фічею, а не багом, та переважна більшість учасників не оголошувала свою особу.
Втім, коли зʼявилися соціальні мережі, то всі дуже швидко втекли туди. Для мене це досі незрозуміле явище. Раптом всім стало цікаво мати свою сторінку, список своїх друзів (а за разом колег, а пізніше — ще й батьків), та все інше спілкування робити в цьому контексті. Можу тільки зробити висновок, що такий режим спілкування переміг, а значить, для змагання з олігополією сучасного інтернету всякий соціальний сервіс повинен бути частиною єдиного великого Федиверсу. Федиверс — це мережа маленьких спільнот, які вільні спілкуватися між собою.
Головним недоліком Федиверсу є його неоднорідність. Серверів та клієнтських застосунків багато, а сумісність визначена на дуже базовому рівні. Тут майже за означенням не може бути такого цілісного досвіду, як у звичайній соціальній мережі. Я впевнений, що це відштовхне всякого не досвідченого технічно користувача. Але в цьому точно є деякий шарм, бо Федиверс залишається “старим” інтернетом, інтернетом для ентузіастів.
Головною перевагою Федиверсу є воля. Тут немає “алгоритмів”. Хоча може на якомусь сервісі є, але ми самі повинні його обрати. Так само модерація є локальним явищем. “Алгоритми” та модерація корисні речі, але не тоді, коли ними керує велетенська безконтрольна корпорація. Тому, я гадаю, Федиверс, з локальними спільнотами, звичаями та законами, ближче до “мрії Інтернету”, ніж то темне місце, в якому ми зараз опинились.
Чи є майбутнє, де Федиверс стане вибором більшості інтернету? Я можу собі це уявити; адже всі ми їздимо на автомобілях різних марок по дорогах різних країн та дістаємось куди треба. Але спочатку щось повинно статись з централізованими мережами.
19.03.2025
ActivityPub
Сьогодні роздивлявся більш уважно протокол ActivityPub, бо є така гадка, що публікувати пости у Mastodon це взагалі зайвий крок. Наприклад, осьо непоганий посібник, як додати ActivityPub навіть до статичного сайту. Але спочатку, що це взагалі значить?
ActivityPub пропонується як “протокол для децентралізованої соціальної мережі”. Якщо HTTP є суто “реактивним” протоколом, ActivityPub формалізує довгострокову підписку на ресурс — тобто він буде проактивно надсилати свої оновлення.
Власне, ActivityPub має більше спільного з SMTP, ніж з RSS. Хоча й побудований на HTTP, а також на JSON-LD (JSON, доповнений схемою). Але доставлення подій тут відбувається за методом Push, а не Pull. Тобто коли ресурс (“актор” на мові ActivityPub) публікує новий пост, то він розсилається всім підписникам — так само як і поштова розсилка. Різниця хіба в тому, що ActivityPub працює симетрично — в кожного актора є вхідна та вихідна скриня.
(Друге, що треба знати, це одиницею інформації в ActivityPub є подія. За природою це Event-Sourced протокол: поточний стан формується як накопичення змін-подій. Створення поста — подія, редагування та видалення — теж, як і поширення та вподобайка.)
Отже, якщо реалізувати на сайті вхідну та вихідну скриню, а також зберігати список підписників, то можна цілком стати частиною мережі ActivityPub, тобто Федиверсу. Набирати підписників, розсилати пости, отримувати коментарі — все це через дві скрині.
Втім головною перепоною для мене є неоднорідність клієнтів. Як показує вчорашній пост, тут все значно гірше, ніж у поштових клієнтах чи читачах RSS. Можна розраховувати тільки на самий базовий HTML. Або… публікувати тільки посилання на сайт. Щось таке. 🤔
18.03.2025
OmniWOPE + Mastodon
Спочатку гарні новини: OmniWOPE вже опублікований! Якщо вам раптом потрібно публікувати блог у канал Telegram, то це вже можна зробити. А далі будемо працювати.
Як тільки я розвʼязав проблеми з телеграмом та перейшов на використання OmniWOPE для цього каналу, наступним чином захотів додати публікацію в Mastodon, про яку так давно думав. Власне, сама публікація — справа нескладна, бо вже є каркас, в який можна додавати більше виходів. (Чого і вам пропоную спробувати, якщо є охота.)
Але ж проблеми зʼявляються із відображенням постів. Якщо брати сам Mastodon, то там все дуже просто, бо він підтримує тільки текстовий зміст. Просто, бо багато не зробиш. Але той сервер що в мене — GoToSocial — хоч і сумісний з Mastodon, але дозволяє публікувати й у Markdown. Та якщо подивитися (зверху) на пост в самому GoToSocial, то наче все більш-менш правильно виглядає.
Проте головна відмінність федиверсу від того ж Telegram - це нескінченне різноманіття клієнтів. Та ще й серверів. Але як я розумію, задача відображення статусу перекладається саме на клієнта — сервер тільки поширює зміст.
Та якщо подивитися на популярні клієнти, то там той самий пост виглядає від недооформленого до повністю понівеченого. Тобто “просто публікувати Markdown” не вийде. Доведеться конвертувати його в такий обрізаний вигляд, який приймуть клієнти. Тобто приблизно так само, як було й з Telegram, але ще й із ретельною перевіркою у різних клієнтах.
17.03.2025
OmniWope - перший пост!
🤞 Нарешті розвʼязав розбіжності в рендерингу постів, про які писав минулого разу. Тож цей пост буду публікувати через OmniWope, а якщо все буде гарно — то наступного дня й сам проєкт OmniWope теж. (Нагадаю, що OmniWope - то мій проєкт для публікації змісту блогу на всілякі платформи.)
Минулого разу також писав про труднощі в оцінюванні часу. Знаєте, тут помилятися можна в обидва боки. Того разу — недооцінив, зате потім переоцінив оті розбіжності та місяць з гаком відкладав. Коли нарешті взяв себе в руки, виправив за 20 хвилин.
Для того потрібно було: зробити так, щоб старий та новий скрипти писали у файли зміст всіх постів. Та порівняти в редакторі ті пости, де є розбіжності. Все! Виявилося, що Hugo автоматично робить першу літеру тегу великою, а значить, в новому скрипті деякі теги змінилися — бо він не вичитує файли самотужки, а бере експорт з Hugo.
Далі знайшов обговорення цього на GitHub, поміняв як там написано та — все! Розбіжності зникли.
Сподіваюся, з публікацією буде все гарно, а там вже й за Mastodon можна взятись (невже майже цілий рік минув?)
16.03.2025
Avowed - гра про білди та дослідження
Avowed - нова фентезійна РПГ від першої особи від Obsidian Entertainment. В таке мені точно хотілося грати. Виявилося трохи зовсім не те що уявляв, але сподобалося.
Avowed - це екшн-РПГ. Головним чином складається з двох занять: дослідження світу та боїв. Тут немає ніякої симуляції світу, це не Skyrim, не KCD та навіть не Cyberpunk 2077. Просто гра не про це.
Система боїв дуже круто зроблена, навіть не знаю, де краще. Багато різновидів зброї, багато навичок, багато ефектів. Ухиляння та парирування. Посилені та критичні удари. Між всім цим гарна взаємозамінність. Наприклад, можна мати “магічну” навичку “підсилення ефекту холоду”, а холод наносити мечем чи рушницю, та ще й доганяти закляттям.
Моя улюблена особливість — що тут завжди можна скинути призначення навичок та атрибутів, за мізерну ціну. Бо навіть на максимальному рівні одночасно можна відкрити хіба що третину всіх навичок. Тобто можна експериментувати вдосталь, та й зовсім змінювати свій стиль гри.
Бої всі групові, хаотичні, та тактично глибокі. В супротивника є стрілки десь нагорі, воїни з щитами спереду, жерці, що лікують, маги, що призивають… Це набагато ближче до Doom Eternal, ніж до Skyrim. Екшн-РПГ, розумієте?
Та друге приємне заняття — дослідження світу. Гра складається з декількох великих та відкритих (та красивих!) зон. Маркери на мапі ставляться тільки на головні завдання. Решту доведеться шукати вручну. Причому на карті є чимало вертикальної навігації — скелі всякі, печери. Та ще й головоломки. А там — секрети, сценки, персонажі, квести… Avowed на рідкість не переймається тим, що ти не побачиш всього цього.
15.03.2025
Коротко про каву вдома
Це якась містика, але останній раз про каву вдома я писав рівно 2 роки тому. От знову про неї нагадали, тому поділюся тим, що може помінялося.
Що не змінилося: якісний еспресо вдома — це як яхта: не хобі, а спосіб життя. Тобто, безперечно можна вдома робити еспресо ще й краще ніж в кавʼярні, бо в кавʼярні немає змоги стільки уваги приділяти кожній чашці. Але прилади, потрібні для приготування еспресо технологічно складні, а тому дорогі. Це треба памʼятати, коли капсульної чи автоматичної кавоварки не вистачає та хочеться чогось більшого.
Мій набір для еспресо це Commandante C40 та Picopresso. Пікопрессо з правильно підібраним помелом дуже непогані результати дає. Але, якщо поруч є кавʼярня третьої хвилі, то навіть такий набір ніщо інше як маленька “яхта”.
Про пуровер. Надбав Дотик. Це українська воронка V60 з унікальною комірчастою структурою. Річ у тім, що керамічні воронки значно відтягують на себе температуру, що помітно погіршує екстракцію. Через це якщо брати класичний Hario, я всяко раджу брати пластик. Або… Дотик! В нього такої проблеми немає. А ще він красивий.
Також збагнув, що головний фактор в пуровері — це рівномірність проливу. Причому звичайним чайником її важко досягнути, бо він надто інтенсивно ллє. Окрім спеціальних чайників з гусячою шиєю, є простіший, дешевший та компактніший варіант: сито Hario Drip Assist. Воно дійсно допомагає.
Нарешті, також отримав штучку під назвою Clever Dripper. Хоч він виглядає, як воронка, Клевер заварює занурювальним способом. Тобто в нього кладеш фільтр, каву, заливаєш водою, чекаєш 3 хвилини та зціджуєш. Звучить як наче надто просто, але кава така ж смачна як з пуровера. Трохи більш насичена.
Отже, Clever Dripper отримує від мене статус найпростішого способу заварити вдома хорошу каву. Настільки хорошим, що тепер я беру щось інше тільки через відчуття, що не виконую свою норму заморочок.
14.03.2025
Патерни програмування
Книжка Gang of Four є мало не обовʼязковим читанням для досвідчених програмістів. А з іншого боку — чув й такі думки, що це нудна академічна маячня, яку ніхто на практиці не використовує. Або що це щось зі світу Hello World Enterprise Edition.
Мені здається, що проблема цієї книжки в тому, як там ретельно розібраний кожний патерн. Це створює уяву, що патерни — це щось стале, як закони термодинаміки чи табличка похідних. Що десь хтось дуже досвідчений пише програми, де кожний клас відповідає патерну з книжки один в один.
Втім насправді ці патерни є формалізацією підходів, які й так існували. В них більше спільного з гуманітарними, а не точними науками. Наприклад, у психології є архетипи, а в літературі - 36 драматичних ситуацій. (Але не все у програмуванні таке “мʼяке”; от, алгоритми вимагають жорсткого дотримання.)
Відповідно, головну цінність патернів бачу в полегшенні комунікації. Фабрика сама собою напишеться, якщо буде потрібна, але спілкуватися з командою легше, коли можна сказати “тут шльопнемо фабрику” та всі зрозуміють, про який підхід йдеться. Або читаєш код, бачиш — адаптер — та відразу знаєш, що клас існує, щоб вставити квадратну деталь в круглий отвір.
13.03.2025
Про переписування
Всі, мабуть, вже чули про компілятор TypeScript переписують на Go. Хотів прокоментувати з позиції людини, яка багато чого переписувала, в тому числі й на Go.
Вони обрали найпростішу форму переписування - 1-до-1. Чудово, що була така можливість, бо не така вона вже й “найпростіша”. Переписати один модуль то вже важко, а тут величезний проєкт. Проте принаймні не доводиться адаптувати структури даних та ієрархію коду під іншу парадигму.
Власне, переписувати 1-до-1 гарно, якщо мови мають схожі парадигми. В разі TS це ще й залежить від стилю програмування; якби код був більш функціональним, навряд чи вдалося б його адаптувати через те, що Go змушує прописати типи кожної функції явно. Але, наскільки я знаю TS, там більш-менш імперативний код, не такий далекий від Go.
Але разом з тим їхній код на Go не такий вже ідіоматичний. Яскрава ознака для мене: бачу лише 125 місць, де з функції повертається error
. Також багато структур, що складаються із функцій — теж ідіома з JS, а не Go. Втім то все можна виправити, головне з чогось почати.
До речі, Microsoft не вперше цікавляться Go - в них є навіть власний форк заради якихось вимог криптографії, які мені важко зрозуміти. А сьогодні дізнався про такий проєкт як [Dapr]https://github.com/dapr/dapr) - теж від Microsoft.
А взагалі, я дуже радий тому, що відбувається: одна з моїх улюблених мов переписана на іншу. 🥳
12.03.2025
Здається, починаю не любити GitHub Actions
Є в AWS офіційна “дія” для GitHub Actions, щоб розгортувати сервіси. Це чудово. От тільки якщо розгортувати достатньо багато сервісів, вона почне відвалюватися з перебільшенням обмеження на кількість. Та ніякого шляху розвʼязку — ані через GA, ані через саму дію — немає.
При тому, розвʼязок дуже простий — збільшити кількість повторних спроб. AWS CLI та всілякі SDK вміють це робити. А дія — ні. Тікет про це висить вже майже два роки. Хтось зробив виправлення, але його дедалі ігнорують.
Можна було взяти форк з виправленням, або зробити свій. Натомість я обрав структурно простіший шлях: замінити виклик дії на виклики AWS CLI. Це трохи складніше, бо прямої заміни немає, треба робити два виклики - aws ecs register-task-definition
та aws deploy create-deployment
. Також треба передавати дані з одного в інший та будувати JSON - що можна зробити з jq.
Зате я отримав рішення, яке побудоване на більш надійних та прозорих компонентах. Очевидно, що AWS CLI використовується на багато порядків більше, ніж це дія GitHub Actions, тому й підтримка в нього краще.
А загальний тут висновок у тому, що треба добре подумати перед тим, як додавати до збірки спеціальні дії. Подумати, в першу чергу, про те, чи не можна замінити її звичайним скриптом. Хоч це і йде всупереч з усією пропозицією GitHub Actions - що весь процес можна зібрати з кубиків, без всякого бридкого коду.
Та й чесно, не дуже в них хороша система для створення тих спеціальних дій. Найгірше — їх потрібно писати на JavaScript, тобто видрати шматок шелскрипта не вийде. Плюс обовʼязково треба додавати до Git повністю зібраний код дії — це наче логічно, але ускладнює розробку.
Якби зараз з нуля переписував систему CI, то орієнтувався б якомога більше на шелскрипти та доступні їм засоби спрощення (як-от звичайнісінький виклик програм, без всякої спеціальної магії.)