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

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

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

Раніше

26.07.2024

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

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

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

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

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

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

25.07.2024

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

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

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

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

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

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

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

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 отримує третину пошти в інтернеті. Хоча якщо підписи стануть примусовими, ми втратимо простий спосіб листування — наприклад, надсилання сповіщень зі скриптів. А поки механізми захисту залишаються необовʼязковими, спам буде жити.

Раніше