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

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

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 таку історію, з якої легко буде пізніше (інколи значно пізніше) зрозуміти причину змін.

Одиницею осмислених змін є пул-реквест. Це значить, що найліпше, коли пул-реквест складається з одного коміту. Що там було всередині — втрачає сенс на широкому часовому масштабі. Пул-реквест гарний тим, що в нього є визначений автор, ціль, обговорення.
Всередині пул-реквесту, в нормі, має бути один коміт. Втім, тут є винятки. Перший виняток — коли пул-реквест складається з декількох логічних кроків, які вирішили не розбивати на декілька окремих пул-реквестів. Наприклад, ми вмикаємо та виправляємо по черзі 5 правил лінтера.
Другий виняток — якщо пул-реквест містить “побічні зміни”. Наприклад, окрім власне нового функціоналу я виправив баг в пакеті тестів. Знов-таки на окремий пул-реквест воно не варте та інколи навіть є перевага від того, щоб розташувати зміни в поєднанні, щоб в майбутньому помітити цей звʼязок. Бо два пул-реквести зі змінами в різних місцях буде важко повʼязати в майбутньому.
Щоб досягти хоч якоїсь організації комітів, необхідно використовувати git rebase. Бо безумовно комітити потрібно набагато раніше, ніж буде готовий весь пакет змін. В межах однієї гілки git rebase (зазвичай) безконфліктний та безпечний інструмент.
Поки гілка ще в роботі, коміти зберігають короткочасну історію змін, що теж корисно. Але коли робота завершена, короткочасна історія витрачає користь — тож під час формування пул-реквесту я роблю rebase та ліплю історію на майбутнє.

16.01.2024

Мій підхід до історії Git

Окрім того, що Git - незамінна платформа координації змін від всієї команди (а я ще памʼятаю “бронювання” файлів у Visual SourceSafe) - є й друга функція. Git - то правдива історія розробки проєкту. Та якщо про координацію змін багато всього написано — всілякі системи гілкування і таке інше, то облік історії не така гучна тема.

Навіщо взагалі потрібна історія? Не для пустих міркувань. Кожного разу, коли я натрапляю на незрозумілий код — я дивлюся на історію його змін. Незрозумілий код зустрічається постійно — під час планування, рефакторингу, пошуку багів. Історія, у формі git blame та git log, розкриває його в новому вимірі.

Замість злагодженої архітектури, в git blame код виглядає як латки, поставлені на латки, поставлені на латки… і так до самої основи. Та коли йдеться про незрозумілий код, то часто легше побачити структуру, коли знаєш, які зміни відбувались одночасно.

Треба дізнатись, яка з форм нова, а яка застаріла? В яких ще місцях зробили — або забули зробити — рефакторинг? Що хотів досягнути автор, коли впровадив помилку? Історія підкаже.

Тому важливо піклуватися про чисту історію. Я вже зачіпляв цю тему, але детальніше розповім завтра.

15.01.2024

Звичайні задачі мають прості рішення

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

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

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

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

14.01.2024

Три місяці з окремим компʼютером для роботи

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

З технічного боку, все досі працює чудово. Мені не потрібні ніякі KVM для перемикання між машинами, коли можна просто фізично перемкнути єдиний USB-C кабель, який йде до доку (CalDigit TS3+). До доку підʼєднані клавіатура, миша, монітор, Ethernet, колонки, вебкамера — і все це швидко та безпроблемно перемикається.

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

Поки не наважився створити для роботи окремий GitHub. Для мене як для програміста виходить так, що саме акаунт в GitHub є головною “інтернет-особою”, та створювати новий, порожній якось.. неправильно. Втім, скоріше за все й до того дойду. Технічно ж майже немає різниці, а на рівні Git так й зовсім.

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

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

Та, звісно, з іншого боку, на роботі легше сфокусуватися, коли на машині є тільки робота. Причому як в моменті, так і протягом дня — легко зрозуміти, чи я “на роботі”, чи “вдома”.

13.01.2024

Огляд фітнес-кільця Oura

З місяць тому мені подарували кільце Oura. Я, власне, нічого революційного від нього не очікував. Наразі я користуюся Apple Watch, та з нарікань до нього хіба те, що в годиннику незручно спати. Але виявилося, що в Oura цікава ментальна модель, яка відрізняється від всього, що я бачив (а бачив я Apple, Fitbit та Garmin). Вона задумана для звичайної людини зі звичайним життям, а не тільки для спортсменів.

Головне те, що Oura пропонує коучінг замість обліку. Набір метрик тут більш-менш такий самий, як з Apple Watch. Але застосунок Oura обчислює з них ряд похідних метрик та порад. Найбільш загальною метрикою є “готовність”, яка показує, наскільки ти в формі сьогодні.

Здебільшого це залежить від якості сну. І тут друга перевага Oura - найбільш детальний аналіз сну, на основі пульсу, варіабельності серцебиття, кількості рухів, часу на засинання та іншого. Навіть температуру міряє.

Також Oura дуже добре автоматично розпізнає як активності, так і сон. Краще, ніж Apple Watch. А ще в переліку активностей є “робота по дому” та “робота на дворі” - завжди на Apple Watch їх бракувало. А ще заряд тримає декілька днів.

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

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

12.01.2024

Обмежена паралелізація в Go

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

iter.Iterator[string, []byte]{MaxGoroutines: 10}.Map(myURLs, func(url *string) []byte {
  resp, _ := http.Get(*url)
  return io.ReadAll(resp.Body)
})

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

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

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

11.01.2024

Map/Reduce в OpenSearch

Сьогодні мав досвід з так званою Scripted metric в OpenSearch. (Така сама є й в ElasticSearch).

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

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

Скрипти пишуться мовою Painless - це звичайна імперативна мова, яка має всі потрібні елементи: масиви, словники, цикли, регулярні вирази.

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

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

10.01.2024

Як зрозуміти велику систему?

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

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

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

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

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

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

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

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

А щодо формату? Дехто полюбляє діаграми, але для мене найкращий формат — то текст. Його швидше редагувати, а саме редагувати доведеться перед усім.

Раніше

Пізніше