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

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

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

26.01.2024

Функція історії в VS Code

🗑️✨ Пост подяки локальній історії в VS Code, також відомої як Timeline. Шукай її на тій самій вкладці бічної панелі, що й каталог файлів.

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

Сьогодні як раз трапилась така халепа, після якої я дійсно поважаю локальну історію. Файл я не просто відредагував, а видалив за помилкою. Причому як раз під час підготовки коміту. До того ж якщо файл видалити не напряму, а “відкинути зміни” в новоствореному файлі, то він не потрапить в смітник, а буде “НАЗАВЖДИ ВТРАЧЕНИЙ”, як попереджає VS Code.

От в такій ситуації я й згадав про локальну історію. Втім, вона працює на рівні файлу, а файл вже втрачений… Здогадався створити файл наново. Та, о диво! Таймлайн цього порожнього файлу містив всі попередні версії. Я вмить повернувся до останньої версії та абсолютно нічого не втратив.

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

PS. Знаю ще аналогічну утиліту Dura, яка автоматично зберігає всі зміни в Git, незалежно від редактора.


25.01.2024

Генеративне тестування

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

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

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

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


24.01.2024

Ruby: ключові слова з опущеним аргументом

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

query = 'SELECT * FROM foos'
option = {timeout: 10, username:, password:}
adapter.execute(query:, options:)

Оці двокрапки мені особисто виглядають, як помилка. Особливо в Ruby, який славиться своїм акуратним та мінімалістичним синтаксисом. Втім, без двокрапки їх було б не відрізнити від нейменованих аргументів, це зрозуміло. В JavaScript, наприклад, підхід простіше, бо там іменовані аргументи — це ті ж самі обʼєкти, та неоднозначності немає (ну, поки ми не хочемо повернути обʼєкт з функції-стрілочки: x => {x} - тоді JavaScript переплутає обʼєкт та тіло функції.)

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

def run_logic(a, b)
# переплутали порядок та не помітили
run_logic(b,a)
# змінили аргумент та не помітили
run_logic(a,c)

def run_logic(a:, b:)
# порядок не має значення
run_logic(b:,a:)
# помилка: немає такого аргументу
run_logic(a:, c:)

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


23.01.2024

Opensearch DSL в Ruby, та чому він мені не подобається

У Opensearch для Ruby є DSL, який, звісно, запозичений в ElasticSearch DSL. Чим довше ним користуюсь, тим менше він мені подобається.

Може я не правий, але цей DSL для мене це приклад “DSL задля DSL”. По суті, він повторює те ж саме, що можна зробити побудовою JSON-у, тільки замість масивів та хешів отримуємо блоки. Зате, бачите, DSL придумали такий, що блоки не передають контекстну змінну всередину — все “красиво”, команди пишуться “чистими”:

definition = search do
  query do
    match title: 'test'
  end
end

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

(До речі, щоб отримати доступ до self всередині блоку, можна призначити його звичайній локальній змінній: me = self. Локальні змінні мають локальну область застосування, їх в нас не відібрати!)

Якщо порівнювати з найуспішнішим DSL для Ruby - Arel - то в ньому завжди контекст (тобто запит в процесі побудови) є явним; його можна зберігати в змінну, передавати аргументом, використовувати багато разів. А не оце все.


22.01.2024

Мої думки про Baldur's Gate 3

Larian Studios навчились робити неперевершені тактичні покрокові бої. Ще у Divinity: Original Sin я побачив глибину рішень, якої просто ніде більше немає. Baldur’s Gate 3, за великим рахунком, успадковує всю базу тієї системи, та тільки фасад перетворює на лад D&D.

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

В Baldur’s Gate 3 поки моя улюблена тактика — пхати. Бо це додаткова дія; вона доступна вже після того, як герой пересунувся та атакував. А гарним поштовхом можна легко відправити супротивника летіти з даху чи скелі.

В іграх від Bioware ніколи такої глибини не було — максимум це стратегічно розташувати героїв та підготуватися до бійки. Тому, якщо тобі бої в Baldur’s Gate 3 сподобались, раджу пограти ще в Divinity: Original Sin 1 та 2. Раніші ігри від Larian зовсім інші. До речі, Divine Divinity - досі дуже цікава гра з епохи Diablo 1, тільки з надзвичайно фізично інтерактивним світом — навіть на цей час.

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


21.01.2024

HomeAssistant та керування через ІЧ

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

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

Далі, як підʼєднати до HomeAssistant ІЧ передавач? В мене вийшло з ще одним розумним пристроєм - Broadlink Universal Remote. Це практично шлюз між Wi-Fi та ІЧ. Залишається змонтувати цю коробочку в місці де вона бачить кондиціонер — та додати в HomeAssistant.

Тепер, про інфрачервоні команди. Кожна команда це послідовність сигналів. Щоб відправляти команди, особливо такі складні, як стан кондиціонера, потрібно їх знати. В теорії, є готові бази команд — можна знайти на GitHub - але, як на мене, легше записати їх власноруч. Як — написано в інструкції по інтеграції. Доведеться трохи підредагувати файли конфігурації, але потім просто направляєш справжній пульт на Broadlink, натискаєш кнопку та команда зберігається.

Перевага HomeAssistant в тому, що він здатний повʼязати абсолютно різні пристрої, та ще й зі складною логікою, та ще й в дружній для інженера формі.

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


20.01.2024

Як в iOS застосунок керує відтворенням звуків

Таємний проєкт застосунку iOS про відтворення картинок отримав трошки уваги. В результаті я дещо вивчив про аудіомодель iOS та виправив неприємний момент UX.

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

Але виникла проблема: програвач, навіть без аудіодоріжки, зупиняв відтворення будь-якого іншого аудіо на пристрої: музики, подкасту і таке інше. Хотілося б дивитися GIFки під улюблений подкаст, тож, що з цим можна зробити?

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

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


19.01.2024

Тобі потрібна директорія-пісочниця

В мене є окрема директорія, куди потрапляють разові скрипти та таке інше. Вона називається playground, та зазвичай вона відкрита в окремому вікні VS Code.

Раніше скрипти писались там, де вийде — інколи в директорії проєкту, інколи просто в довільному місці - “Документи” чи “Завантаження”, чи “Робочий стіл”. В моменті з цим проблем немає — аби працювало.

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

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

…А потім, через пів року після того, як “разовий” скрипт відпрацював та був забутим, зʼявляється потреба написати його ще раз. А він вже написаний! І готовий до виконання. Приємно!


18.01.2024

Docker як обгортка для команд

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

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

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

До контейнера можна примонтувати всі файли та директорії, які потрібні, причому Docker не буде їх копіювати, а зробить доступними через віртуальну файлову систему (яка, маю признати, на macOS працює трохи повільніше, ніж нормальна.)

Вся команда виглядає так (тут опція --rm видаляє контейнер по завершенню, а решта, сподіваюсь, зрозуміла:)

docker run --rm \
    --mount type=bind,source='$(shell pwd)',target=/mnt \
    --mount type=bind,source='$(shell go env GOCACHE)',target=/tmp/gocache \
    --env GOCACHE=/tmp/gocache \
    buildpack-deps:latest \
    make -C src/tool

Скажу більше, в мене така команда сидить всередині if, який перевіряє: якщо ми на CI на Linux, то можна просто запустити make локально; а якщо на macOS з Apple Silicon - тоді в Docker. Економно — наскільки це можливо — та прозоро для користувача.


17.01.2024

Хороша історія в Git - моя практика

Як вчора писав, в мене завжди є (неявна) задача створити в Git таку історію, з якої легко буде пізніше (інколи значно пізніше) зрозуміти причину змін.