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

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

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

05.05.2025

Середовища для тестів та для розробки

От вже не знаю, наскільки це поширено, але в Rails в тебе локально завжди є два екземпляри середовища. Одне — для розробки - development - містить сталі дані. Друге — для тестів - test - витирається начисто на кожний запуск тестів. В “середовище” завжди входить база даних, але також може бути кеш, набір файлів тощо. Ну, та ще й належна конфігурація.

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

Але я навіть не про те хотів сказати. Я, з подачі колеги, ось що згадав: інструменти для налаштування тестового середовища значно зручніше, ніж робочого. Причина проста — тестове середовище ми відтворюємо багато-багато разів, а робоче… ну може коли новий працівник приходить, чи після якоїсь катастрофи. Гарно, коли для розробки є скрипт (в Rails це seeds.rb), але за досвідом він майже завжди застарілий, бо його майже не використовують. Та й локальне оточення буде застарілим, якщо єдиний спосіб його оновити — це все перестворити наново.

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

А якщо піти далі (що й пропонував колега), то можна запустити інтеграційні тести з відкритим браузером, а посередині поставити на паузу та далі взаємодіяти із застосунком в потрібному стані.

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

04.05.2025

Цикли ефективності

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

🐹 Режим хомʼячка — це коли робиш те, що спадає в очі. Згадав — зробив, не згадав… не зробив. Звісно, здебільшого робиться гостре. А також багато цікавого; особливо цікаво починати нові справи, а не закінчувати старі нудні. В такому режимі можна теж робити круті речі, але рідко ті, що не вимагають від себе уваги.

🧨 Накопичення роботи — зазвичай з таким ставленням стає дедалі більше справ. До того ж справи, які були важливі, але не термінові, не робляться, та згодом стають терміновими. Поступово “режим хомʼячка” створює більше та більше стресу.

💥 Криза — тиск росте, росте, та нарешті просто вимагає організуватися. На щастя, я знаю, як це робити, бо досвід є. (Власне, з першої кризи та першого пошуку рішення все й почалося.)

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

🌸 Ефективність — з налагодженою системою робити прогрес стає легко! Навіть ті проєкти, на які хом’ячок дивився як на фантазії, піддаються аналізу та поступовому прогресу. А ти згадуєш ще більше цілей. (Ідеї люблять порожню голову!)

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

😵 Та все починається наново — система розвалюється, та я знову починаю робити те, що горить або цікавить. До нової кризи…

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

03.05.2025

Синдром непотрібного узагальнення

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

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

Або приклад, який я й помітив: оцінка тривалості задачі. Теоретично, вона може бути будь-яка. Але фактично, мене цікавить: чи встигну я зробити задачу десь в перерві (5-10 хвилин), або чи встигну за “підхід”, тобто за одну-дві години. А якщо довше, то її вже можна розбивати, бо фактично більшого безперервного відрізка часу в мене не буде. Отже, немає сенсу думати про точну тривалість у хвилинах.

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

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

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

02.05.2025

Що я любив у Pivotal Tracker

…Якщо в мене й був улюблений трекер робочих задач, то це Pivotal Tracker. Той, що два дні тому закрився, та ще й так суворо, що навіть стилі блогу злетіли — а можливо, невдовзі зникне й сам блог. Згадаю, чим Pivotal Tracker був такий хороший.

(Я навіть давно писав клієнт командного рядка, а потім інтеграцію з OmniFocus). А колеги з роботи писали доповнення для Chrome. Одним словом, років 15-10 тому це було прямо явище.)

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

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

Але ця сфокусованість була й недоліком Pivotal Tracker. Він вимагав дуже чіткого процесу розробки (можна було б сказати - Agile - але це слово може значити аби що.) Ну, наприклад: PT автоматично бʼє роботу на спринти, дивлячись на оцінки та швидкість виконання. Для цього потрібна однорідна команда, де хто завгодно може підібрати задачу.

Pivotal Tracker був продуктом із вбудованою методологією. Що в цілому не так далеко від того, як я сам думаю про продукти, та вважаю, що це чудовий підхід, коли ця методологія є (У Pivotal Labs - величезної та успішної фірми з розробки — була.)

До речі, з живих досі продуктів мені ще подобався Shortcut, тоді відомий як Clubhouse. В нього із Pivotal Tracker є дещо спільне. А ще хтось зробив сайт Goodbye Tracker, де зведені понад 10 альтернатив — деякі дуже зрілі!

01.05.2025

Штучний інтелект — хто виграє від нього найбільше?

Перше, виграють виробники потужностей. Всі великі виробники компʼютерів вже вийшли з “AI” пристроями. Дуже вчасно зʼявилася причина оновити компʼютер, бо якщо не дивитися на “AI”, то останніми часами компʼютери стали достатньо потужні, щоб не думати про наступний. (Бо в моєму дитинстві компʼютер оновлювали, щоб на ньому можна було подивитися фільм.)

“AI” це золота жила тому, що його можна продавати будь-кому — від малої дитини до панів в костюмах. Зокрема, подивимося на відеокарти. Ресурси для відеоігор досягли стелі якості, за якою їх нерентабельно виготовляти. Та й ринок все одно обмежений. А тепер можна скільки завгодно потужностей продати заради “АІ”.

Хоча понад усе виграють власники хмар. Бо, цілком очевидно, що ніж купувати дороге залізо, можна заплатити хмарі. Тому, коли зараз кажуть, що пристрої “з AI” не мають попиту, я гадаю, що споживачу хмари достатньо. Наперекір сумнівному ставленню хмарних компаній до етики — про яке можна судити вже з того, що вони вже тренують моделі навіть на піратському контенті.

Друге, це ринок стартапів. У тому вузькому сенсі, як продуктів, які будуються, щоб отримати інвестиції або продати задорого та швидше. Інвесторів легше переконати, коли за тобою стоїть Технологія Майбутнього, Яка Тільки Відтулила Двері Для Найрозумніших — хай то бізнес в інтернеті, соціальні мережі, блокчейн чи тепер AI. Тому серйозні стартапери не шукають революційних ідей, а застрибують в поточний Віз Революції та галасують якомога гучніше, що Віз справжній, а хто на нього закине грошей — поверне їх встократ.

Я поки не добрався до того, що ж все ж таки “AI” здатний чи не здатний робити, як-от генерувати красивий ввічливий лист, або, наприклад, підсумувати задовгий лист до його змісту. (Жартую.) Давайте так — багато на що здатний. Про це іншим разом.

30.04.2025

SwiftUI - рефакторинг та оточення

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

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

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

Цей стан в мене поки зберігався просто в @State var formModel на структурі застосунку, та передавався глибше через @Binding. Цього разу я прикинув, через скільки шарів доведеться прокинути @Binding та вирішив, нарешті, переробити.

У SwiftUI є можливість, схожа на контексти в React - це Оточення, @Environment. Нею можна передати вглиб структури презентації якесь значення. Але — саме значення, не змінну, редагувати його не можна.

Або… можна? Спочатку я спробував передавати функцію-сетер, setFormModel. Це спрацювало! Далі пошукав більш ідіоматичне рішення та знайшов, що взагалі-то в @Environment можна передати Binding(FormModel), та тоді його можна буде призначати через formModel.wrappedValue = newFormModel.

(Binding, який лежить в основі моделі стану SwiftUI, як раз і є абстракцією над гетером та сетером, яка загортає змінне значення у незмінну обгортку.)

Код став гнучкіше та чистіше. До речі, в останньому SwiftUI цей @Environment значно спростили, так що якщо давно не бачили — подивіться.

🕜🏷️ Нагадаю, що я пишу Ping - застосунок на iOS для нетрадиційного обліку часу. Якщо цікаво, до бети можна доєднатися тут.

29.04.2025

Кращий час для виправлення технічного боргу може бути зараз

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

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

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

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

Виходить, чим успішніше проєкт, тим менше треба відкладати на технічний борг. На сьогодні логіка така.

27.04.2025

Застосунок для покращення оцінок часу

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

Ідея в тому, що якщо давати оцінку, а потім заміряти справжній час виконання, то можна побачити розбіжності та згодом зробити оцінки точніше. Я не раз чув про такий підхід, але не знайшов застосунків. (Здивуйте мене!) Хоча, звісно, застосунок дуже простий — таке собі поєднання таймера та секундоміру.

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

Бо так, я передбачив, що задачі ж повторюються, та чим більше вимірів, тим більше впевненості. Тому кожен “експеримент” відбувається не в ізоляції, а в контексті якоїсь “активності”.

Та ще є сповіщення, які я вже навчився робити по-всякому. Одне сповіщення — на “заявлений” час виконання, друге — на середній час (тобто “емпіричний”). І ще можна повторювати в час, кратний заявленому - щоб зовсім сумно стало.

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

27.04.2025

Як я робив TG-бота для самоменеджменту

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

Власне, ось навіть код виклав.Я писав його влітку 2017-го, але сьогодні легко завів. Бо це Go, а не React Native. У Go підтримка легасі — це одна з головних цінностей дизайну. Ще треба зазначити, що в Telegram дуже зручна модель розробки ботів, тож ти його можеш запустити в себе локально та створити власного бота. Поки програма запущена, бот буде доступний будь-звідки через інтерфейс Telegram.

Як бот влаштований. Фактично бесіда з ботом — це “вікно” в дані, яке фокусує нашу увагу на чомусь одному (наприклад, поточній дії.) Задача бота — просувати це вікно, а також пропонувати ефективні та вчасні операції в поточному контексті. Це досить особливий бот, можу порівняти його з людиною-тренером, або з інтерактивною літературою, тільки ще й з твоїми даними всередині.

Головна складність в тому, що він повинен памʼятати стан бесіди, причому навіть після довгої паузи. А бесіда має складну блок-схему (“обробка вхідних” в GTD вже складна!)

Я роздивлявся різні моделі та вирішив розбити спілкування на пари “питання-відповідь”. Кожне питання має: код-ідентифікатор, “шаблон інтерфейсу” - текст та кнопки, та обробник відповіді.

(До речі, оці кнопки - це лише “заготовлені відповіді”, тобто немає різниці, натиснути на кнопку чи ввести її текст вручну. А також тому можна обробляти кнопки та вільний ввід одночасно, в одному “питанні”.)

Обробник інтерпретує відповідь, робить належні зміни в базі, та надсилає повідомлення про результат. Результатом обробника завжди є нове питання, яке набуває чинності та отримує шанс побудувати вже власний “інтерфейс”. Наприклад, ось питання action_suggestion з ілюстрації.

Таким чином вдалося ізолювати логіку кожного кроку. Щоправда, я на той час не здогадався класти додатковий стан, як-от поточну дію, в поле JSONB, а записував прямо в спільні поля в моделі користувача. Це погано, бо в кожного питання може бути своє розуміння “поточної дії”.

Мені цей проєкт, з одного боку, подобався та досі подобається за його інтерфейс. Є щось особливе в тому, щоб працювати з даними в режимі діалогу (що на цей день стало тільки актуальніше.) А з іншого, діалог обмежує. Зокрема як тільки треба передивитися всі дані в базі, та ще й робити над ними зміни. Були в мене фантазії гібридного застосунку — тобто такого, де діалогова модель доповнює традиційну - але руки не дійшли.

26.04.2025

OmniWOPE: публікація ілюстрацій в Mastodon

Хотів сьогодні насправді писати зовсім інший пост, але для нього потрібна була ілюстрація. А їх мій скрипт для публікації — себто OmniWOPE - не вмів викладати в Mastodon. Нарешті цей недолік виправлено, та зображення повернуться в мій канал.

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

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

Ще виявилося, що треба ж оголосити тип медіа. (До речі: сьогодні дізнався, що саме “тип медіа” сучасна назва, а не “тип MIME”.) Досі для Telegram мені було потрібно тільки знати, чи є ілюстрація зображенням чи відео. Та нарешті, чомусь вбудований у Go метод multipart.Writer#CreateFormFile не дозволяє призначити тип медіа! Та найкраще рішення для того — скопіювати та виправити код методу.

На сьогодні все. Нову версію вже можна забрати з GitHub.

Раніше