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

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

05.03.2024

Традиційний застосунок — найкращий хобі-проєкт для вебінженера?

Якщо ти заробляєш веброзробкою, то голова генерує ідеї вебсайтів та вебзастосунків. Хочу звернути увагу, що, може, то не найкращий вибір для маленького проєкту, та краще спробувати себе в “традиційних”, тобто “локальних” застосунках. Для iPhone, для Android, для настільних ОС — взагалі, до того, чим користуєшся. Мої аргументи:

Можна попрацювати з цікавими мовами та фреймворками, з якими не стикаєшся на роботі. Або - загорнути знайомі вебтехнології. В будь-якому разі, розширити знання та отримати нову перспективу.
Застосунок легко розгорнути: для себе взагалі не потрібно, а для знайомих можна через TestFlight (а для macOS/Windows/Linux - взагалі поділитися файлом.)
Традиційним застосункам доступні всі можливості компʼютера — від графічної карти до вебкамери — та операційної системи — від віджетів до файлів — та з них можна зробити дійсно особливий досвід. Наприклад, все планую зробити застосунок смуги меню, який буде оповіщувати про тривоги з AWS. (Якщо такий вже є, прошу поділитись, а якщо ні — дарую ідею!)
Тому з застосунків виходять чудові проєкти для себе чи для близьких: вони за природою приватніші, при тому не потребують авторизації.
Навіть якщо запускати його у широку публіку, то, можливо, вдасться уникнути сервера — а це, можливо, найскладніша та при цьому непомітна та неоцінена частина. Для розробника-одинака це заощадження (як по часу, так і по грошах!) може бути визначальним фактором.

04.03.2024

Ще 10 днів зі стохастичним таймтрекером

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

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

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

Одне діло думати “я надто багато часу сиджу в телефоні”, та зовсім інше — бачити, що сидіння в телефоні у топ-10 активностей за тиждень (топ-1 виходить “сон”, до речі, а топ-2 “сидіння за компʼютером”… теж є над чим подумати.) Причому це більш точний показник ніж функція телефону “екранний час”, бо тег “в телефоні” значить, що я буквально в цей час дивився в телефон… відмазок немає.

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

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

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

03.03.2024

Особливості Swift Charts

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

Swift Charts - трохи незвична для мене бібліотека (а звична то D3 або Highcharts). Вона є повністю декларативною та високорівневою, тому коригування вигляду відбувається високорівневими та абстрактними засобами.

Ну, наприклад: щоб спрямувати шкалу у зворотному напрямку, потрібно… передати їй обʼєкт “області визначення”, та в ньому вказати напрямок. А щоб шкала точно включала значення від 0 до 24, в цю область визначення додаються ці межі:

.chartYScale(domain: .automatic(reversed: true, dataType: Double.self) { domain in
  domain.append(0)
  domain.append(24)
})

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

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

02.03.2024

Любов до таблиць

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

Наприклад, потрібно мені було нещодавно залучити модуль golang.org/x/text/encoding для перекладу тексту з одного кодування в інше. Але ось в чому справа — цей модуль немає абстракції, де кодування визначається назвою. Натомість там є низка реалізацій типу Decoder для різних кодувань; виходить, що ми маємо наперед знати, яку саме Реалізацію взяти. А я знаю тільки назву кодування.

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

…Знаходжу в інтернеті гарний документ, близький до стандартного, з переліком кодувань та їх можливих назв (бо у назв є синоніми: наприклад, ISO-8859-1 та latin1.) Тут включається любов до таблиць, я забуваю про пріоритети та починаю перекладати документ в код. Весь. Хоча ні — цього разу помітив та зупинився, звідки й пост.

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

Так само мене спокушають переклади коду з мови на мову, інтеграції з API, специфікації форматів файлів… все, де можна відключити мозок та писати код рядок за рядком.

01.03.2024

Sync та Async: покрокове програмування

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

Може, я переграв у Baldur’s Gate 3, але виконання рівночасних програм нагадує покрокову гру. Програма складається з послідовних блоків, які виконуються по черзі. (Принаймні, абстракція така — що там насправді відбувається, нам невідомо — процесор, ОС, та середовище виконання всі накладають свої нюанси.)

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

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

29.02.2024

Майже порожній аркуш

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

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

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

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

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

28.02.2024

Водяне охолодження — керування

🎛️ Як я згадував в пості про компоненти, в системи охолодження немає власного керування. Всі активні компоненти — помпа та вентилятори на радіаторі — керуються звичайним PWM з самого компʼютера.

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

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

Щоб розвʼязати цю головоломку, знайшов надзвичайну програму FanControl. Вона вміє встановити швидкість вентиляторів як функцію комбінації датчиків. Замість простої кривої, як в BIOS, тут справжній ЦОС. Єдине, що FanControl запускається вже з Windows, а до того в BIOS виставлено вмикати помпу на безпечно високу швидкість.

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

27.02.2024

Водяне охолодження — трубки

🚰 Якщо всі вище згадані компоненти відносно взаємозамінні у своєму класі та залишається тільки обрати ті, що подобаються, то на трубки залишається 80% архітектури.

Взагалі трубки є гнучкі та тверді. Гнучкі — з ПВХ, тверді — акрил чи ПЕТ. Чув, що варто брати спеціалізовані, бо звичайні трубки випускають в воду мікрочастинки, які зрештою забʼють радіатори, а це дуже неприємно. Плюс, трубки для водяного охолодження враховують нагрівання, під час до 50 градусів.

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

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

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

26.02.2024

embed.FS - включення файлів у програму на Go

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

//go:embed resources/*.html resources/*.css
var resources embed.FS

index, err := resource.ReadFile("index.html")

У embed є дві форми: окремий файл та директорія. Файл в програмі стає звичайним рядком: дуже зручно. А директорія перетворюється на тип embed.FS, який сумісний з модулем io та тому підходить для багатьох споживачів — наприклад, можна роздавати ці файли по HTTP за допомогою http.FileServerFS.

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

25.02.2024

Водяне охолодження — з чого воно складається?

Система водяного охолодження має форму замкненого контуру з елементів, які поєднані трубками. На відміну від побутового водопроводу, який знаходиться під тиском, в системі охолодження вода ходить по колу, а значить, розгалужень бути не може. Відповідно, в кожного елемента завжди є один вхід та один вихід. Які то компоненти?

Теплообмінники (waterblock) - заміняють повітряні радіатори. Це важкущий блок з металу, який притискається до мікросхем, а всередині бігає вода та забирає тепло. Практично має сенс встановити теплообмінник на процесор та на відеокарту — хоч можна знайти й блоки для інших компонентів, але то вже зайве.
Радіатор (radiator) - який віддаватиме тепло у навколишнє середовище. На радіаторі будуть вентилятори — такі самі, які й в повітряній системі. Радіатор найскоріше кріпиться на корпус компʼютера. Сенс всієї системи в тому, що вода ефективно передає тепло від мікросхем до радіатора, а з радіатора можна ефективно “здути” тепло назовні — замість того, щоб вибудовувати складні повітряні потоки всередині корпуса.
Помпа (pump) - забезпечує потік води. Помпа — це єдиний новий активний елемент. Вода в системі мусить постійно рухатись — без цього вона перегріється. З погляду програмного забезпечення, помпа — це лише ще один “вентилятор”, який регулюється стандартним розʼємом. Часто помпа поєднується з бачком.
Бачок (reservoir) - просто містить резерв води. Резерв потрібний, бо вода завжди випаровується. Та й взагалі дуже складно було б без бачка заповнити всю систему без пухирів повітря — а пухирів нам абсолютно не потрібно, бо з ними охолодження не буде.

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

Раніше

Пізніше