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

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

Підписатись на RSS · 📢 Канал в Telegram @stendap_sogodni

Раніше

Пізніше

03.08.2024

Емоції та думки

Абсолютно незаплановано рівно рік потому повертаюсь до теми емоцій. Також незаплановано мені сталося послухати дві книги про “поліпшення настрою” з досить схожими назвами: Feeling Good та Letting Go та схожими оцінками на Amazon та Goodreads. Обидві обговорювали емоції та думки. А головний збіг те, що ці дві книги розкривають тему з діаметрально протилежних боків.

Feeling Good ставила тезу: “навʼязливі погані емоції — це наслідок хибних думок.” Всі наші емоції є продуктом автоматичних міркувань. Через аналітичну роботу з думками можна виправити вади міркувань (наприклад, схильність перебільшувати проблеми), а коли негативні думки зникнуть — то з ними й емоції.

А Letting Go, навпаки: “погані думки — це наслідок законсервованих поганих емоцій.” Непрожиті емоції накопичуються та створюють постійне напруження, а з ним — і думки. Людину з законсервованим злом все буде злить. Людина з образою всюди знайде несправедливість. Через усвідомлення та проживання можна позбавитись накопичених емоцій та тоді ті самі обставини будуть викликати більш позитивні міркування.

Як може бути, що обидва підходи, вочевидь, працюють? Гадаю, тут немає суперечності: думки та емоції існують пліч-о-пліч та утворюють петлю зворотного звʼязку. До того ж одним людям легше працювати з думками, іншим — з емоціями. Чудово знати, що в тебе є вибір.

02.08.2024

SMTP vs Email API

Я вже колись писав про те, який SMTP повільний та як там дивно реалізоване шифрування. В цілому, якщо ви надсилаєте пошту через сервіс та він підтримує HTTP API (як Mailtrap), та клієнт теж здатний надсилати по HTTP, то так і треба робити.

Але сьогодні передивлявся питання про наш сервіс з StackOverflow та викрив ще одну, дуже важливу причину надсилати пошту через HTTP API. Порти, через які надсилають пошту, будуть скоріше заблоковані.

Стандартний порт SMTP 25 взагалі блокують майже всюди, бо саме цей порт використовується для отримання пошти, а значить — це єдиний спосіб розсилати спам. Для підключення з клієнтського застосунку на сервіс надсилання пошти використовуються інші порти - 587 та 465. Але і вони дуже часто будуть заблоковані про всяк випадок — хоча надіслати пошту безпосередньо отримувачу за цими портами неможливо.

Надійний спосіб — це дозволити клієнтам надсилати через якийсь “неофіційний” порт — наприклад, 2525. Я гадаю, що так і треба робити, якщо є можливість, щоб уникнути подальших проблем. Проте все одно гарантій немає. Деякі хостинги (та системні адміністратори) заради безпеки попросту блокують всі порти, окрім необхідних. Та, виходячи з питань StackOverflow, це реальна проблема.

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

01.08.2024

Просунуте використання Dash

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

В простому вигляді раджу призначити Dash до комбінації клавіш; в мене це Hyper+D. Так документація завжди під рукою. Але сьогодні захотів піти далі та інтегрувати Dash у VSCode. Інтеграція знає мовний контекст, тому відразу відкриває сторінку правильної мови. Хотілося, щоб вона також працювала за комбінацією Hyper+D… щоб цього досягти, залучив BetterTouchTool та створив там привʼязку “Hyper+D у VSCode = Ctrl+H” (комбінація пошуку з доповнення.) Так у VSCode активується доповнення, а в будь-якій іншій програмі - Dash напряму.

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

Але ще цікавіше що документацію можна генерувати власноруч. Причому раніше для того було потрібно писати павуків та будувати базу SQLite, то зараз все суттєво спростилося: Dash вміє завантажити цілий сайт, а потім вже підчистити нашим JS/CSS. Нагадало, як на початку 2000-х завантажував всілякі енциклопедії програмою Teleport Pro.

31.07.2024

Розподілені транзакції в Sentry

Розбирався вчора з цікавою ситуацією з моніторингом продуктивності від Sentry. (Мікровідгук: в цілому мені цей продукт подобається, він хоч і не такий виточений як New Relic, але свою задачу виконує успішно.) Ситуація була в тому, що в проєкт насипалося забагато подій — а з кишені висипалася пропорційна сума грошей.

Зазвичай ми не зберігаємо прямо кожну операцію в Sentry. Це було б очевидно надто витратно. Для того є параметр traces_sample_rate - так можна знизити частоту хоч до кожної 100-ї операції, хоч до 10000-ї - як хочете. Також є можливість задати складніший алгоритм в параметрі traces_sampler: наприклад, можна зберігати тільки ті операції, що впливають на наше поточне дослідження продуктивності; або ті, що були надто повільними тощо.

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

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

30.07.2024

Власні віджети для AWS Cloudwatch Dashboards

В сервісі моніторингу AWS Cloudwatch є можливість вбудувати в дешборд не тільки графік чи журнал, а й абсолютно власний зміст. Віджет фактично є вікном до AWS Lambda-функції.

Хочу сказати, що це зручний спосіб надати обмежений доступ до ресурсів. Взагалі AWS Lambda добре підходять для інкапсуляції доступів. А в разі віджетів в нас ще й авторизація готова, та стилі, та й деякі особливості інтерфейсу: наприклад, можливість обрати діапазон часу, або увімкнути автоматичне оновлення.

Лямбда в віджеті може повертати довільний HTML/CSS… а чого вона не може, так це містити JavaScript. (От, сьогодні дізнався про елемент <summary>, яким можна згорнути блок без всякого JS.) Також віджет може містити внутрішню навігацію, але особливим чином: у вигляді спеціальних посилань на інші AWS Lambda. Оскільки посилання може йти на ту ж саму лямбду (з іншими параметрами), отримуємо можливість зробити маленький вебзастосунок.

Ось тут я стикнувся з проблемою… параметри до функції не зберігаються під час оновлення віджета — він скидається до початкового стану. Тоді знайшов, що хоч параметри не зберігаються, зате функція отримує ‘особливим параметром widgetContext стан форм, якщо такі є на віджеті. Тоді зробив помірно закручений код, де наявні параметри виводяться у <input type="hidden" /> - а якщо явних параметрів немає, тоді навпаки, дивлюся в зміст цього поля.

29.07.2024

Покращення до css_parser - тепер в PR

Нарешті знайшов час зробити два PR до бібліотеки css_parser для Ruby, про які я писав рік тому, а зробив ще у 2021-му. Кілька спостережень.

28.07.2024

Тулінг

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

В моїй практиці багато випадків, де задача просто не може бути виконана готовими засобами в розумні терміни. Мені згадується стаття You can’t buy integration; теза якої: так, існує безліч готових рішень для будь-яких задач та проєктів. Але “останній крок” до розвʼязку все одно доведеться робити нам.

Я чимало зустрічав згадок про визначні інструменти всередині Google або Facebook. (Ось, наприклад, цілий “перекладач” з внутрішнього тулінгу Google на відкриті альтернативи.) На жаль, так відбувається не просто тому, що великі компанії такі розумні, а через те, що в них є резерв часу розробників, який може вкладатися в інструменти (а також експерименти та все інше.)

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

Інші приклади: внутрішні лінтери для підтримки домовленостей. Дешборди для оцінки ситуації. Кодогенератори для прискорення типових задач.

27.07.2024

Конфігурація Obsidian у dotfiles

Продовжую уніфікувати оточення за допомогою dotfiles та Chezmoi. На черзі Obsidian: хоча б заради того, щоб стилі для канви були однакові. Дізнався дещо нове про Obsidian.

Щоб просто залучити файли, проблем немає: chezmoi add ~/vault/.obsidian та й годі. Конфігурація Obsidian міститься в файлах, в решті решт. Деякі файли є специфічними для оточення, їх прибираю: bookmarks.json, workspace.json, starred.json.

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

До речі, про підтримку: в Chezmoi є корисна команда chezmoi diff, яка вказує всі розбіжності dotfiles зі справжніми файлами. А також chezmoi unmanaged - перелічить ті файли, які ще не контролюються chezmoi. Тобто в цілому немає проблем, щоб змінити налаштування в самому Obsidian, а потім зберегти в dotfiles. А ще є chezmoi merge для того, щоб інтегрувати зміни — вона працює для шаблонів. (Файли без шаблонів можна просто скопіювати.)

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

26.07.2024

Списки задач, GTD та вичерпність

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

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

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

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

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

25.07.2024

Культура ввічливого обходу

🚸 Обходи (або ж “хаки”, а взагалі ми їх частіше називаємо англійською - “workaround”) - це шматки коду, які написані не так, як ми хочемо, а так, як довелося через проблеми в чужому коді котрий ми не контролюємо. Часто тимчасово — до виходу виправлення. Щоб код не наповнювався загадковими нелогічними рядками, обходи потребують чіткої демаркації.

👉 Як мінімум потрібний коментар: # це обхід, через таку причину. Коментар допоможе побачити (та пробачити), що наступний код написаний не за правилами. (Бо знаєте, трапляється й таке, що бачиш дивний код, починаєш рефакторити… та через пів години розумієш, що так робити не треба було, бо код був хаком.)

🍝 До речі, рефакторити обхід — зазвичай погана ідея… принаймні коли відомо, що потім його доведеться прибирати. Це той випадок, коли краще зробити прості (структурно) зміни та залишити їх. А якщо обхід стосується декількох місць — то варто перелічити їх в коментарі: # не забути подивитись на foo.rb та bar.go, коли будеш прибирати.

📦 Окремо цікаво, коли обходи стосуються залежностей. Я не люблю package.json та go.mod за те, що в них не можна додати коментарі. Натомість в Gemfile в Ruby можна додати скільки завгодно. Тут коментар виглядає як # під час оновлення перевірити цей файл та таку поведінку.

🎫 А в ідеалі в коментарі до кожного обходу повинен бути тікет. Або такий, що вже існував та ми його тільки знайшли на GitHub - або можна (та варто!) створити власний.

Ось мені довелося освіжити файли конфігурації оболонки та дуже не вистачало пояснень до того, чому я написав декілька дивних рядків.

Раніше

Пізніше