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

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

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

19.07.2024

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

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

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

• Обробити всі нотатки. Нотатки збираються по ходу роботи, особливо на дзвінках. Краще обробляти їх щоденно, але не завжди так виходить. До речі, “обробити” для мене значить по GTD зʼясувати, чи потребує нотатка дій, чи відкласти її на майбутнє (в канву “мабуть/колись”), або завести в поточні справи.

• Обробити “збережені повідомлення” в Slack. Завжди користуюся цією функцією, щоб не втратити важливі дискусії, ідеї та обіцянки. Процес тут такий самий, як з нотатками (просто зберігати повідомлення в нотатки не так зручно.)

• Переглянути відкриті PRи. Я щодня передивляюсь сповіщення від GitHub, проте час від часу власні PRи забуваються та за браком активності вже не зʼявляються у сповіщеннях. Регулярний огляд допомагає про них згадати.

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

• Зробити маленькі справи. Завжди зустрічається кілька справ, які ну немає сенсу записувати на майбутнє — не тільки тому, що їх робити швидко, а й тому, що контекст з часом втратиться, та разом з ним — цінне, можливо, покращення. Тоді беру та роблю на місці. В GTD є “правило двох хвилин” - тут виходить скоріше 10-15 хвилин. Але ж треба згадати, що на відновлення контексту потім може піти набагато більше (або, що більш ймовірно, задача буде скасована).

• Актуалізувати проєкти. Нарешті, переглядаю весь список проєктів (за GTD) та передивляюсь, щоб вони були ще в роботі, а також щоб в кожного була хоч одна справжня наступна дія.

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% браузерів. Плюс, за моїми перевірками, для такого завдання різниця невелика.

14.07.2024

Технічні проблеми з іграми на macOS

Я тимчасово відірваний від свого ігрового компʼютера (навіть Parsec не допоможе, бо він просто вимкнений.) Залишається в щось пограти на макбуці. Але, навіть коли він включений у монітор, клавіатуру та мишу, геймінг з маком залишається чимсь особливим… щоб його любити, доводиться йти на компроміси.

• Чомусь не всі ігри здатні змінити роздільну здатність. Тобто багато ігор запускаються тільки з надвисокою “рідною” роздільною здатністю монітора (бо в кожного маку пікселів в три-чотири рази більше, ніж здається), та через це не витягують по швидкодії. Хоча процесори Apple Silicon здатні на багато — як за графічним потенціалом, так і емуляцією процесорів x86, яка нам дуже знадобиться.

• Грав в Doomlike Prodeus (до речі, дуже гарний); все б добре, але як тільки стріляєш, гра гальмує. Ну, думаю, ефектів накидали багато, макбук не витримує. Знизив всі налаштування до мінімуму — не допомогло. Нарешті розкопав, що справа взагалі не в графіці, а в тому, що функція “магнітних вікон” від BetterTouchTool перехоплює керування, як тільки ти натиснеш кнопку миші. Ну… як так?

• А трохи пізніше помітив, що активне резервне копіювання Backblaze веде до затинання. Що з того, що Game Mode увімкнений (взагалі не знаю, що він дійсно покращує.) Все одно доводиться вручну ставити на паузу. (А взагалі Backblaze гарне рішення, та й компанія гарна — рекомендую.)

• Немає доступних функціональних клавіш. Перше, що втрачаєш — це швидке зберігання та завантаження. Тому я для себе всюди призначаю їх на \ та /. Також в мене є комбінація для перемикання ролі Fn-клавііш з медійних на звичайні… але тоді втрачаєш регулювання гучності. Якщо не привʼязати його окремо через той же ж BetterTouchTool. Та й все одно ненадійно.

13.07.2024

Емулятор відповідей SMTP

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

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

Тому ми вбудували у Mailtrap емулятор відповідей. Достатньо надіслати листа, наприклад, на bounce+555+spam@inbox.mailtrap.io, та система відповість: 555 spam. Звісно, це працює навіть для користувацьких клієнтів, таких, як GMail - до речі, цікаво було подивитися, як він реагує на тимчасові помилки (тобто з кодами 4xx).

Зміст відповіді додається до адреси отримувача з URL-кодуванням. Чому обрали саме адресу? Бо це працює не тільки в будь-якому клієнті, а й навіть тоді, коли ти не контролюєш зміст листа (наприклад, тих листів, що надсилаються застосунком.) Адреса отримувача - найгнучкіший з усіх доступних носіїв.

Але, це змушує нас кодувати зміст (який може бути довільним рядком ASCII) в набір символів, доступний в імені скрині електронної пошти. Обрали кодування URL, бо воно залишає зміст читабельним. Нюанс: за стандартом поштові адреси зводяться до нижнього регістру, тому якщо у відповіді потрібні великі літери, їх також доведеться закодувати: Spam стане %53pam. На жаль, стандартні кодувальники цього не зроблять, хоча механізм кодування URL не забороняє будь-який символ замінити на його код. В майбутньому щось для цього придумаємо.

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

12.07.2024

Хліб

🌡️ Літо — найкраща пора року, щоб почати пекти хліб. Тісто любить підвищену температуру — те, що взимку потребує часу або підігріву, влітку відбувається непомітно. Особливо коли йдеться про закваску; а на заквасці хліб найзапашніший та найхарактерніший.Наприклад, мій “звичайний” хліб взимку готується з обіду до наступного пізнього ранку, а влітку він готовий вже увечері.

Для мене домашній хліб почався з подорожі в Австрію, де я скуштував дуже простий житній хліб на заквасці. У нас такого практично не купиш; або суміш з пшеницею, або щось солодке. Знайшов рецепт. Сподобалось.

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

Наразі я печу хліб з цілозернової спельти. Рецепт тут. Спельта в нас почалася як “здорова альтернатива пшениці”, але як виявилось, вона просто смачна: духмяніша за пшеницю, легша в роботі ніж жито (яке сходить ну дуже важко.) Поки нічого кращого не треба.

Нарешті, можу порадити книгу Ібана Ярса “Домашній хліб”. Мені сподобалось, що рецепті в ній “відкриті”, а техніки добре проілюстровані. Також автор пояснює, як правильно використовувати дріжджі. Гарний посібник.

11.07.2024

Go-global та важливість правильного повідомлення про помилку

Несподівано з новим застосунком натрапили на таку помилку в go-global:

global: : cannot write param: config key is of unsupported type struct

(Go-global це наша бібліотека для завантаження структур параметрів. Останній раз оновлював її ще рік тому, втім, зазвичай вона свою функцію виконує та проблем не створює.)

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

cannot write param: destination should be a primitive type, not a struct

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

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

no parameters in Parameter Store with prefix "/foo/"

Отакої! А без вірного повідомлення навіть я як автор бібліотеки не міг зрозуміти, де криється справжня помилка.

10.07.2024

Перегляд журналів до CodeDeploy

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

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

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

Для того довелося: з API витягнути розгортування; потім з нього “специфікацію застосунку”; потім з неї “дефініцію задачі”, а також назви Lambda-функцій, що роблять перевірку на здоровʼя; нарешті по назвах знаходжу конфігурації функцій, та з них та дефініцій задач можна здобути групи журналів, які стосуються розгортування. Фух! Не тільки складно, але й досить спеціалізовано; мабуть, саме через це вони самі логи й не показують.

Але це ще не все… з груп залишилося знайти потоки. (Я колись писав, що в Cloudwatch “потік” відповідає конкретній задачі.) Для того я більш хитрим, ніж базові API, шляхом відтинаю всі потоки, які не збігаються за часом. (Як не дивно, такого API немає; максимум це перелічити потоки за зменшенням часу.)

А потім всі результати складаю в шаблон HTML та відкриваю в браузері. В терміналі теж гарно, але я може ще якийсь UI додам зверху.

….Альтернативним шляхом було б формулювання запиту до Cloudwatch Insights. Тоді можна було б зупинитися на групах + діапазоні часу розгортування. Так, може, було б і краще.