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

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

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

Раніше

Пізніше

14.09.2022

Мій досвід з Clojure

🧙☕🏕️ Сьогодні якось згадалась між словом мова Clojure, яку я обожнюю, хоч не використовую.

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

А проте, досвід, набутий з Clojure, залишився зі мною на довгі роки. Тому, на мою думку, цю мову корисно випробувати кожному інженеру.

Якщо хочеться глянути на 50 рядків красивого коду на Clojure, пропоную мою імплементацію OAuth.

13.09.2022

Чому мені не подобається модель REST

🎂👮🍱 Сьогодні день програміста. Вітаю з 0х100!

Поскаржуся трохи на REST, як систему організації HTTP API.

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

Тепер про погане: як і будь-яка система, модель REST не описує всі операції. Наприклад:

Оскільки у Ruby on Rails дуже зручно створювати API для ресурсів, то є тенденція натягувати на REST абсолютно все, до фанатизму. Так виходять ресурси на кшталт bulk_imports або, ще гірше, publishs - тобто з дієслова штучно робиться іменник. А ще HTTP-методи окрім GET та POST не повністю підтримуються браузерами — спробуйте зробити DELETE через форму.

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

REST - для явних ресурсів. Для всього іншого - POST по шляху з назвою дії.

12.09.2022

AppleScript для зберігання вкладок у Reeder

🤖✨🔖 Позавчора я розповідав, який зручний список читання у Reeder. А вчора навідкривав десь 40 вкладок (передивлявся архів Hacker News), після чого зрозумів — чого Reeder не вміє, це додати у список відразу всі вкладки. Що ж робити?

Сьогодні скористався вбудованими засобами автоматизації, щоб це виправити. Спочатку хотів написати AppleScript. Це давня та езотерична мова, яка надає доступ до даних запущених застосунків. З допомогою AppleScript можна отримати перелік всіх вкладок з Safari - після того, як трохи пограєшся з “наближеним до людської мови” синтаксисом.

Але є проблема. AppleScript працює тільки з тими застосунками, що його підтримують — оголошують власний API. На жаль, Reeder так не робить. Проте виявилось, що він підтримує Shortcuts - більш сучасну систему автоматизації. Shortcuts прийшов з iOS і дозволяє збирати скрипти з графічних блоків.

Shortcuts не працює з вкладками Safari. Зате, в шорткат можна вбудувати шматочок AppleScript (або JavaScript, або шелл-скрипта.) Оскільки скрипт я вже написав, залишилось додати до його результатів цикл та операцію додавання до Reeder. Тут теж не без хитрощів — треба, щоб між кроками збігались типи даних — але в цілому Shortcuts простіше у використанні, ніж AppleScript.

Готовий шорткат можна зашарити, а ви можете подивитись за посиланням. Дивна система поширення шорткатів — каталогу немає, просто ти отримуєш посилання і все.

11.09.2022

Бот для відправлення постів у Telegram

🤖🤝😁 Сьогодні метапост: я запостив цей пост за допомогою бота, який теж написав сьогодні. До цього пости публікував вручну через додаток Telegram.

Навіщо це потрібно? Є декілька важливих переваг:

Телеграм-бота створити досить нескладно — для Go є бібліотека, а реєстрація проходить через телеграм-бот @BotFather та займає хвилину.

До того ж для публікації постів потрібен не бот, а просто скрипт. Ідея скрипту проста: для телеграм-каналу створив окремий тип постів (а блог в мене на Hugo); також тримаю файл з відповідністю постів до ідентифікаторів у Telegram. Перед публікацією в Hugo запускаю скрипт, який запостить або оновить пост в Телеграмі, дивлячись на файл відповідностей.

Все б було ідеально, якби Телеграм не вимагав суворого екранування символів для Markdown (наприклад, треба екранувати дефіси та крапки.) Спробую для наступного поста HTML.

10.09.2022

Як я зберігаю список статей на майбутнє за допомогою Reeder

👓☕📰 Окрім RSS-читача та RSS-генератора, незамінною частиною мого читального арсеналу є сервіс "список для читання".

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

Найбільш відомий список для читання — на мою думку, Pocket, тож пропоную роздивитись його. Що не рекомендую, це вбудований список для читання з Safari. А я натомість користуюсь списком, вбудованим в обраний мною RSS-читач Reeder. Що я в ньому полюбляю:

- це програма, що працює локально, а не вебсервіс; до того ж, вельми приємна
- підтримує як мак, так і айфон, та синхронізується через iCloud
- має інтеграцію в діалог поширення — тобто посилання можна легко додати з будь-якого місця, як на маці, так і на айфоні.

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

Отже, десь так я і споживаю новини:

- підписуюсь на джерела — або безпосередньо, або за допомогою генератора
- продивляюсь повністю всі стрічки за розкладом (щотижня)
- додаю все цікаве в список читання
- нарешті, куштую статті зі списку на дозвіллі ☕

09.09.2022

Загрози простою AWS SSM Parameter Store та як їх уникнути

🔥🧑‍🚒🔥 Сьогодні простій того самого сервісу AWS SSM Parameter Store, який я так хвалив нещодавно, спричинив 3 години простою нашого. Як так сталось?

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

Але був нюанс. Той самий SSM використався також у хелс-чеку. Та коли SSM зламався, то хелс-чек почав видавати помилку. Це спричинило нездоровий стан додатка та його перезапуск. А коли додаток перезапустився, то й він підхопив ту ж саму болячку... і вже не піднявся аж допоки SSM не повернувся до життя.

Стислі висновки:

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

08.09.2022

Оповіщення AWS СloudWatch для сервісів ECS

🌡️🎛️⚠️ Продовжив сьогодні налаштовувати оповіщення Cloudwatch. Облаштував сервіси ECS (тобто, аплікації.)

Два оповіщення тривіальні — на високий рівень утилізації процесора та памʼяті. Ці дві метрики повідомляє сам ECS.

- Памʼять — на 80%. Сервіси на Ruby дуже полюбляють памʼять, але 20% треба тримати в резерві.
- Процесор — на 50%. Якщо у вебсервісу постійне навантаження до 50%, скоріш за все щось відбувається не так. Зазвичай більшість часу вебсервіси чекають або на базу, або на клієнта, тобто процесор простоює.

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

Це створює дві категорії проблем. Першу досить легко побачити — це зіпсований деплой. Задеплоїли, не завелося, все нібито працює, але на тлі нескінченно стартують та зупиняються поламані задачі.

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

Отже, хитрим поєднанням AWS EventBridge, Cloudwatch Logs, Log Metric Filter, та потім власне Metric Alarm, можна зробити так, щоб події зупинки задач ECS потрапляли до журналу, фільтрувалися за причиною (бо є ще очікувані зупинки) та підраховувались метрикою.

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

07.09.2022

День хотфіксів

🔥🧑‍🚒🚨 Сьогодні в нас день хотфіксів, може п'ять разів випускали. (То добре, що процес деплою на це готовий.)

Пара постмортем висновків.

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

- Автоматичні тривоги — це критична частина інфраструктури. А саме: в ситуації, коли у вас ламається сервіс, а ви це помічаєте вручну через години (або хвилини), або вам повідомляють користувачі, треба попіклуватись і додати тривогу, щоб наступного разу про поламку було відомо одразу. Ось, сьогодні додав тривогу на довжину черги повторів у Sidekiq. Ще шукаю можливість зробити тривогу на високу кількість перезапусків задач в ECS.

06.09.2022

Чому варто занести свої DNS-записи до Terraform

🔍🗺️🕸️ Сьогодні пораджу як зручно керувати DNS записами. А саме, варто записати їх у Terraform. Terraform - не тільки для того, щоб керувати інфраструктурою AWS; він також дозволяє описати практично будь-які налаштування, за наявності відповідного провайдера. (Провайдер — це плагін, що дозволяє Terraform робити зміни в деякому сервісі.)

Зазвичай реєстратори DNS (Godaddy, Namecheap, та інше) мають вкрай незручний інтерфейс. Особливо якщо у вас декілька доменів, то керувати всіма записами вручну це страждання. Добре що зазвичай ці записи налаштовують один раз та далі вільні про них забути; погано, що такий важливий аспект продукту так важко роздивитись.

Так от, замість того, пропоную перенести конфігурацію DNS-записів в Terraform. Існують провайдери для всіх визначних реєстраторів. Якщо ж для вашого немає, можна переїхати, наприклад, на Cloudflare - вони надають DNS хостинг безоплатно.

Terraform замінить складні та незграбні веб-інтерфейси простими конфігураційними файлами. А якщо ви робите багато однотипних записів, то повторення навіть видасться "підсушити".

05.09.2022

MonkeySort - цікавий інструмент для сортувавання за вподобаннями

🧹🕸️🐒 Сьогодні раптово згадав та освіжив один зі своїх стародавніх проєктів - MonkeySort. Тобто точніше, згадав один з користувачів (виявляється, такі є!) А проєкт за десять років перестав працювати через більш суворі вимоги браузерів до CDN. Треба було змінити посилання на HTTPS, але замість того я всі залежності додав до самого проєкту. До речі, великий плюс до стабільності Google та Cloudflare CDN, що вони все ще працюють. На таке можна покластися.

Що, власне, за проєкт? Про це є стаття, а якщо у двох реченнях, то це експеримент по сортуванню предметів, у якому порядок визначає людина, що порівнює їх попарно. Наприклад, так можна відсортувати задачі за складністю, або улюблені страви. Головна ідея в тому, що багато речей складно порівняти, а дві речі — легко.

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

Відразу зрозуміти, що відкинути — дуже складно і боязно. Тому замість того я оцінюю кожну річ за шкалою на п'ять "балів":

- Річ на 1 бал відразу викидається.
- Речі з 2 балами теж викидаються без розбору, але не миттєво, а після закінчення оцінок (так вже легше це прийняти).
- Якщо після цього все ще залишається багато речей, то речі на 3 бали знов сортуються таким же ж чином, але вже проміж собою.
- Речі на 4 бали — це те, що майже напевно хочеться залишити, їх і не чіпаємо.
- І, нарешті, 5 балів — це стовідсотково цінна річ.

Звісно, оцінювати треба швидко, покладаючись на інтуїцію.

Раніше

Пізніше