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

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

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

Раніше

Пізніше

24.07.2024

Підготовка dotfiles з Chezmoi

Я досяг початкового успіху — зробив єдині dotfiles на дві системи macOS та одну Linux (а точніше, Codespace). Дійсно дуже допомогло те, що в Chezmoi є шаблони. Інакше я б все ще шукав власне рішення (та чомусь не маю єдиного вірного варіанту шаблонізатору.)

Приклад розбіжності: на macOS в мене налаштований підпис комітів з GPG. В Codespace підпис теж працює, але іншим способом: агентом, який був наданий оточенням. З шаблонами це дуже легко обійти: {{ if eq .chezmoi.os "darwin" }} та так далі.

Була проблема — в Codespace все відбувається повільніше. Розгортування dotfiles (а саме, встановлення залежностей) триває декілька хвилин. Це не так погано для користування, але жахливо для розробки, коли нічого ще не працює. Тому знайшов образ, який використовують Codespaces та написав скрипт, щоб запускати все локально в Docker, приблизно отак.

Причому з Chezmoi в мене система, де я можу внести правки з будь-якої з систем та розповсюдити їх на інші через git. Якби не було, то файли забруднюються локальними змінами та потім вже доведеться наново все збирати. (Як в мене вже траплялося.)

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

23.07.2024

Chezmoi - менеджер для dotfiles

Знайшов Chezmoi - гарну утиліту для керування dotfiles. Це, порівняно зі згаданим в коментарях stow, цілий комбайн, але мені то подобається, бо розвʼязує майже всі потреби, які в мене були. Одну не розвʼязує — це як зробити свої dotfiles достатньо публічними для публікації. Тому цього робити не буду.

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

Далі, дуже важливо, що файли можуть бути шаблонами. Причому Chezmoi написаний на Go, тобто це шаблони Go, звичні мені за Hugo (та й за роботою теж.) Для шаблонів заготовано чимало функцій, включаючи інтерактивне введення значень та навіть читання з 1Password та інших менеджерів. Також шаблонами можна відокремити конфігурацію для різних машин — це теж важливо. Причому, до речі, Chezmoi має підтримку всіх можливих платформ, включаючи Windows.

Є механізм завантаження додаткових файлів. Навіть цілий репозиторій Git можна завантажити та розгорнути. Така потреба виникла в мене відразу.

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

Добре, що Chezmoi розрахований на повторні запуски — є навіть особливий синтаксис chezmoi update для оновлення репозиторію та застосування змін в одну команду. Бо dotfiles гарні тільки тоді, коли їх можна тримати актуальними.

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

22.07.2024

Як я робив Linux на Windows у 2010

З 2016 року в Windows вбудована WSL - можливість встановити Linux та працювати з ним одночасно з Windows: прямо відкрити консоль, запускати сервіси — та все не виходячи з Windows. Я коли це побачив, відразу знав, що це круто — бо сам робив таке саме ще 6 років тому за допомогою продукту під назвою colinux.

Не знаю, скільки людей користуються таким підходом зараз, бо обставини, безумовно, змінились. Зокрема, у 2010 Linux на ноутбуці був обʼєктивно неповноцінним. Найгірше то те, що не було нормального рішення для сну: або вимикати ноутбук повністю, або поступово витрачати батарею та гріти рюкзак на “неглибокий” сон. У Windows був режим Hibernate, який зберігав стан памʼяті та вимикав живлення.

Але… на Windows було надзвичайно складно працювати з Ruby. Багато бібліотек мали помилки, або просто не підтримували цю платформу. До того ж Ruby потребує командного рядка, а в Windows з цим історично погано. (В порівнянні, стек Apache + MySQL + PHP був цілком надійним.) Тобто потрібний був компроміс.

Щоб запустити Linux, можна було взяти VirtualBox. Але, в такого рішення був ряд недоліків: машини VirtualBox працювали в ізоляції, мали окрему файлову систему, мусили бути запущені вручну щоразу. Не те, чого хотілось. Тоді знайшов coLinux - цей продукт запускав ядро Linux як сервіс Windows - автоматично, у фоні, та з доступом до тієї самої файлової системи.

От тільки чого не було, так це зручного терміналу. Доступ до Linux відбувався по SSH через PuTTY. Рішення трохи неповноцінне. Натомість дізнався, що графічна система Linux - X11 - взагалі є клієнт-серверною, та здатна працювати навіть через локальну мережу. А для Windows теж є сервер X11: Xming. Через підключення до нього я запускав Rxvt як графічний емулятор термінала на Linux, а вікно зʼявлялося на Windows та чудово себе почувало з такими зручностями як буфер обміну. Так само запускав й GVim: так, Vim є й для Windows, але ж під Windows він не мав би доступу до робочого оточення.

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

21.07.2024

Інцидент з Crowdstrike: операційне фіаско

Не люблю коментувати про поточні події, але в історичному інциденті з Crowdstrike є чому повчитись.

Досить швидко знайшли причину помилки — причому, як сторонні дослідники, так і в самій компанії. Дехто привʼязав її до вад мови C++. Для мене це рефлексія програмістів на класичну тему “чия мова краще.” Хоч в C++ є свої недоліки, але я ще не зустрічав мови, в якій не буває помилок. Особливо на стику системної інтеграції. Для мене наявність помилок в програмі — неуникна реальність.

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

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

20.07.2024

Логи та топологія

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

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

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

Поки не знайшов інструменту такого “топологічного” перегляду журналів. Та ще й AWS CloudWatch - не дуже зручна база. Фактично вони пропонують лише два способи перегляду: або конкретний потік (гарно тільки коли ти точно знаєш, яка копія сервісу цікавить), або пошук запитом Log Insights - це хоч і гнучко, але писати щоразу запит дуже втомлює.

19.07.2024

Тижневий огляд на роботі

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

Тижневий огляд складається з таких кроків:

18.07.2024

Dotfiles

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

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

Але, з появою у житті Codespaces потреба загострилася. Бо Codespace не є сталим оточенням; гарно, коли можеш легко створити його наново. Та для того Codespaces як раз підтримують dotfiles - не треба нічого вигадувати.

На жаль, останній раз я збирав dotfiles ще тоді, коли працював у GVim та Rxvt через Xming на Windows. Тобто тепер можна починати наново. Буду радий почути рекомендації по фреймворках та інші поради.

17.07.2024

Як надсилають пошту спамери

Я не раз писав про всілякий захист від спаму, але тепер хочу подивитись з іншого боку. Як спамерам вдається обійти підписи та інші механізми?

Проблема спаму не у відсутності механізмів захисту, а в тому, що неможливо змусити всіх ними користуватися. Якщо дійсно робити всі перевірки, то надто багато “чесної” пошти буде відкинуто.

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

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

Чи прийдемо ми колись до екосистеми SMTP, де кожний лист правильно підписаний та аутентифікований? Рухи в цьому напрямку робляться: GMail тепер вимагає від листів більше захисту. Та в них є така змога: GMail отримує третину пошти в інтернеті. Хоча якщо підписи стануть примусовими, ми втратимо простий спосіб листування — наприклад, надсилання сповіщень зі скриптів. А поки механізми захисту залишаються необовʼязковими, спам буде жити.

16.07.2024

Мій досвід резервного копіювання

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

Arq Backup - чудова програма, що вміє робити резервну копію будь-куди — від локального диска до всіх можливих хмарних сховищ. Я почав користування з власного NAS, а пізніше переїхав на AWS S3, а потім — на Google Drive. З цієї історії можна зробити два висновки. Так, це дійсно дуже круто, коли ти можеш обрати, де зберігати резервну копію: за ціною, географією, лояльністю до бренду. Але: з такою програмою будь готовим адмініструвати місце призначення та піклуватись про нього.

З негативного: Arq Backup зберігає локальний індекс сховища (якщо вірно згадую), та згодом цей індекс стає великим. Тут ще треба дивитися на характер резервного копіювання: я люблю зберігати практично весь зміст диска, окрім очевидно непотрібних. Можна заощадити не тільки на місці, а й на системних ресурсах, якщо обмежитися важливими файлами.

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

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

15.07.2024

Генерація кольорів для CSS у 2024

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

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

Проте RGB - не єдина модель кольорів, та сучасний CSS підтримує інші. Модель — це спосіб задання кольору через координати. Наступна за підтримкою — модель HSL, її підтримують 99% браузерів. Для нас важливо, що в HSL можна зафіксувати яскравість та насиченість, а змінювати відтінок. Таким чином генерація сумісних кольорів стає майже тривіальною:

`hsl(${(i * 360) / count} 50% 50%)`;

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

Ще є модель LCH/Lab - вона ще краще, бо в HSL яскравість не завжди відповідає сприйняттю. Але LCH підтримують тільки 91% браузерів. Плюс, за моїми перевірками, для такого завдання різниця невелика.

Раніше

Пізніше