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

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

31.10.2022

Перші враження від Obsidian. Тести з Redshift.

🪨📓💫 Що ж, переніс нотатки в Obsidian. Перші враження дуже приємні, як вже писав, працює швидко, інтеграція з Git вбудована. Знайшов ще важливу властивість — при перейменуванні чи пересуванні нотатки всі посилання на неї будуть виправлені автоматично. Що стане до нагоди, коли я буду впорядковувати базу, для чого і шукав більш зручну програму.

Дуже зручно мати глобальну комбінацію клавіш для пошуку та додавання нотаток. Таку комбінацію можна створити програмою BetterTouchTool - для цього дія на комбінацію має бути “відправити ⌘+O програмі Obsidian, перед чим вивести її на передній план”.

По роботі писав та тестував SQL-скрипти, що мають працювати на AWS Redshift. Великий недолік Redshift - у неї немає локального емулятора. При цьому мова помітно відрізняється від Postgres - настільки, що тести для Postgres недостатні. Багато разів було таке, що навіть після ретельного тестування код не працював, і дізнавались про це тільки на стейджингу. Тому у нас на CI тести (RSpec) запускаються також і з Redshift. Це надзвичайно повільно — ця база не розрахована на транзакційні операції. Маю ідеї переробити тести на щось більш сумісне — наприклад, замість створення тестових даних на кожний тест окремо, підготувати базу для всіх тестів один раз.

30.10.2022

Перенос нотатків з Bear до Obsidian, перші враження

📓🐻🪨 Подивився більш уважно на Obsidian - додаток для збереження нотаток. Почав переїжджати (до того в мене все було в Bear і трошки невпорядкованого в Drafts.)

Чому саме Obsidian:

Працює зі звичайними файлами в теці. Це я люблю.
Але при цьому вміє показувати зображення. Також дуже цікаво, що він підтримує формат YAML Frontmatter, та за допомогою цих метаданих можна побудувати справжню базу даних на свій смак.
Мобільна версія існує та її можна синхронізувати через звичайний iCloud. Підтримує навіть плагіни.
О плагінах: їх можна писати на TypeScript. Тобто можна побудувати для себе автоматику, процеси та інше. Є, наприклад, плагін, що зберігає зміст бази в Git. Це зручно не тільки для резервного копіювання, а також і для історії. Колись давно я такий робив самостійно та окремо для nvALT, а тут вже все вбудовано в сам Obsidian, і знає, коли ти зробив зміни. Або ж є плагін, що робить з нотаток дошку канбан. Чого немає, а я хочу зробити, це автоматична архівація всіх вебсторінок, на які є посилання.
Спритний! В мене понад 2000 нотаток, та ніяких гальмувань я не побачив. Немає їх і з великими нотатками (в мене є нотатка з повним текстом ПДР — все добре. Також і нотатка з резервною копією 700 посилань-закладок.)

Експортувати нотатки з Bear просто та очевидно, але ж мені ще хочеться побудувати з них Git-репозиторій, та при цьому зберегти дати останнього редагування. (До речі, при експорті Bear сам виставляє правильну дату зміни файлів. Це половина успіху!)

29.10.2022

Багажник на дах

🚗🧳🎿 Сьогодні про автомобільні багажники на дах. Мав нещодавно купувати, виявилось не так просто. Може, і вам стане до нагоди.

Нащо це потрібно? Ну то зрозуміло — додаткові 300-400 л місця, дуже зручно при кочовому образі життя. До того, якщо вже обладнати дах машини під багажник, то далі можна туди кріпити й ровери, і лижі, і човен, і намет, і меблі… можливостей багато.
Багажник — справа дуже відповідальна. При поганому закріпленні чи неправильному користуванні улетить на трасі, якщо повезе — то не в чужу машину. Треба ставитись серйозно.
Багажник обмежує максимальну швидкість до 130 км/г. Це зрозуміло, бо він очевидно погіршує динамічні показники машини — гальмування повільніше, в поворотах трохи, але помітно несе. Що цікаво, витрати палива в мене менше за звичайні — напевно, через обмежену швидкість.
Край боксу опиниться десь на 30 см вище даху. Залазити туди складно. Особливо якщо у вас SUV.
Сам по собі бокс по розміру нагадує ліжко і важить близько 30 кг. Тобто знімати його з даху нелегко, а для зберігання треба мати гараж. Є цікаві механізми для монтування боксу на стелі гаража, я ще не роздивлявся.
Для кріплення багажника до машини на даху мають бути рейлінги. Є кріплення без них, але вони притискаються безпосередньо до даху, і, як на мене, то несерйозно — хоча б тому, що псуватиме фарбу.
Якщо рейлінгів немає, то, зазвичай, їх можна докупити. Є всілякі моделі від сторонніх виробників, але ж на мою думку оригінальні будуть надійніше. Я купив оригінальні повздовжні рейлінги — для них на даху підготоване місце. Потім, поперечні від THULE. До поперечних йде адаптер під конкретну модель машини, а взагалі вони модульні, складаються від власно рейлінгів, кінцевиків, та кріплень-адаптерів.
Сам бокс кріпиться до поперечних рейлінгів. І бокс, і поперечні рейлінги можна рухати взад-вперед. Головне, це щоб бокс підійшов по довжині — не заважав заднім дверям, та не дуже нависав над лобовим склом. Тож перед тим, як обирати бокс, варто виміряти довжину даху, це головний показник.
Отже, перелік необхідних покупок: рейлінги повздовжні оригінальні, рейлінги поперечні (комплект), багажний бокс. Все це не дуже дешево, але ж ще раз кажу, що заощаджувати на надійності нераціонально.

Можу ще порадити офіційний магазин THULE в Україні - bagazhnik.ua. (Вони мені не платять.)

28.10.2022

Чому робочі питання треба обговорювати в спільному чаті.

💬👥📖 Всі робочі питання в команді краще обговорювати в спільному чаті. Приватний чат залишається для особистих питань - “коли зустрічаємось”, “як справи”, “ходімо на обід” та інше.

Але все, що стосується розробки проєкту — в спільному. На мою думку, саме такої політики треба дотримуватись, та регулярно нагадувати собі та іншим. Чому саме так?

Питання. Якщо ставити питання приватно, то відповісти має той, кого запитали. Це створює блокер — один чекає, другий має терміново відповідати. Також це підвищує bus factor, бо не дає іншим членам команди використати свої знання. Тому краще питати публічно, навіть якщо здається, що відповідь знає хтось конкретний.
Обговорення. Ніхто ніколи не тримає весь контекст проєкту водночас, тому завжди є шанс, що дехто з команди відкриє ще невідомий бік питання. Також обговорення в спільному чаті роблять рішення відомими всім та відразу. Якщо ж обговорювати приватно, то хибні рішення будуть помічені пізніше і коштуватимуть дорожче.
Історія. Зміст публічного чату можна знайти пізніше. Є питання та ситуації, що виникають знову і знову. Так, ідеально було б задокументувати кожне, але я не вірю, що хтось так робить. Але якщо просто обговорювати публічно, то журнал чату — це вже документація. Я часто шукаю (та знаходжу!) висновки з обговорень, зроблених рік чи більше тому. Звісно, документацію це не скасовує. Наприклад, розвʼязок кейсів підтримки можна почати в чаті, а потім перенести в повноцінну базу знань.

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

27.10.2022

Зручніше відображення даних з бази HealthKit

⚖️📉💚 Нарешті, можу проілюструвати, що я мав на увазі, коли казав, що вигляд даних у вбудованому додатку Health залишає бажати кращого.

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

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

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

Систему з середнім я придумав не сам, а прочитав багато років тому у книзі Hacker’s Diet. То є легендарна книга, яку варто прочитати кожному інженеру, що хоче схуднути. Написав її засновник компанії Autodesk.

До речі, нічний режим у SwiftUI надається автоматично, якщо вживати палітру системних кольорів. Дуже зручно.

26.10.2022

SwiftUI після React - враження

📱📐🎨 Потрохи просуваюсь зі своїм проєктом на HealthKit та тепер на SwiftUI. Скористуюсь нагодою розповісти трохи про SwiftUI і як на ньому писати після React.

Всім відомо, що SwiftUI був створений, щоб йти в ногу з часом саме з React та іншими схожими фреймворками. Це добре.

Перше слабке місце SwiftUI - відсутність JSX. JSX це чудова технологія, бо з одного боку надає можливість описувати структуру елементів та атрибутів наочним чином, а з іншого боку, еквівалентна JavaScript/TypeScript коду та піддається всім технологіям роботи з кодом — рефакторингу на функції та модулі, формальній перевірці та інше.

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

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

Щоб почати, варто відразу зрозуміти, що аналог Redux будується на основі ObservableObject. Тобто в простих випадках можна зберігати стан в компоненті, як і в React, але при подальшому розвитку краще винести логіку в клас з ObservableObject.

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

Ще раджу продивитись офіційний курс по SwiftUI, він багато чого прояснює.

25.10.2022

Ми є то, що ми робимо щодня

☀️🌚🫂 Ми є то, що ми робимо щодня. Це дуже потужна думка.

Майбутнє є неосяжним. Спланувати його, а потім слідувати плану, мало кому вдається.

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

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

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

24.10.2022

Як Сloudflare бореться з атакою DDoS

💩🚚😬 Сьогодні весь вечір боролись з виснажливою DDoS атакою. Довелось випробувати, на що здатний Cloudflare. Отже, декілька спостережень:

Платний план захищає суттєво краще, ніж безплатний (а у нас як раз чомусь скасувався платний, можливо, через перемикання картки.) Кількість заблокованих запитів більше у 20 разів. Думаю, це тому, що на безплатних користувачах Cloudflare і дивиться, який клієнт неблагонадійний. Хоча якщо грошей немає, то все одно від чогось Cloudflare вас захистить.
Автоматичне блокування не ідеальне, тому раджу в реальному часі дивитись на характер запитів, та вручну створювати правила до фаєрволу. Так надійніше. Та, звісно, автоматичні правила продовжуватимуть роботу.
Треба вмикати режим “під атакою”, тоді всі відвідувачі будуть проходити через JS перевірку. (Security level -> Under Attack.) При цьому, щоб не поламати API, для нього за допомогою Page Rules треба поставити інший рівень безпеки (і заздалегідь).
Окремо нас порадував плагін Wordfence для WordPress. Здається, атака переповнила його базу, та вичерпала ресурси сервера. Вимкнули плагін повністю, бо за Cloudflare в ньому немає сенсу.
Налаштуй сповіщення про DDoS, щоб не чекати скарг клієнтів.

А тепер, буду встановлювати macOS Ventura. 🌻

23.10.2022

HealthKit - все ж таки краще на SwiftUI, ніж на React Native

🍏🪶❣️ Сьогодні пробую свій проєкт з HealthKit почати писати на Swift. Головною причиною є бажання поекспериментувати: я давно хочу зробити на SwiftUI щось реальне, і, може, на цей раз вдасться.

З роками Swift та SwiftUI помітно дорослішають, та писати на них все менш і менш боляче (сказати “приємніше” ще не виходить.) Все тут чуже: мова та її парадигми, стандартна бібліотека, модель додатка, навіть редактор (програє VSCode за можливостями розширення та за зручністю) та документація (не дуже зручна і не дуже гарно написана.) Ніяк не можу заохочувати писати на Swift, якщо воно вам не треба.

Тому, до речі, я великий прихильник React Native: вийде не набагато гірше, але на знайомих технологіях. Цим не варто нехтувати.

Але все ж таки, що у Swift є такого, що у RN немає, або є, але гірше? Головне, що я знаю — це база Core Data, а особливо CloudKit, тобто синхронізація через iCloud. Зараз в RN немає гарного рішення — тож якщо вам потрібна якась синхронізація, треба мати бекенд, авторизацію і таке інше. Натомість у Swift дані синхронізуватимуться між пристроями без зайвих дій та акаунтів. Але, якщо ви робите додаток для вже наявного сервісу, то це не має значення.

Також будь-яка системна інтеграція — а їх чимало — завжди ускладнюється у RN. Наприклад, як в моєму випадку HealthKit: бібліотека у Swift достатньо обʼємна, тому повної обгортки для RN немає.

Можна зробити й гібридне рішення: модуль на Swift, який буде передавати до React Native необхідні значення — тобто замість API загального призначення, зробити вузький API для вашої бізнес-логіки. Це в мене зараз план C.

22.10.2022

Пост посилань. Copilot, Obsidian, Twitter, DuckDuckGo, macOS

🔗🔎📢 Сьогодні буде пост посилань. Давно вже хотів це спробувати, оскільки щосуботи читаю новини.

Тривають розслідування порушень авторських прав сервісом GitHub Copilot. Ми в компанії вже вирішили, що краще їм не користуватись. А як альтернатива вже давно є TabNine, що має локальний режим.
У програми для збереження нотаток Obsidian вийшла версія 1.0. Вона дуже потужна, попри те, що нотатки зберігаються у звичайних текстових файлах. Але мене поки що зупиняло те, що вона зроблена на Електроні.
DHH міркує про те, чи потрібна велика команда великому проєкту. На мою думку, принаймні потрібно достатньо інженерів, що будуть працювати на підтримку та забезпечення стабільності.
Цікавий закон Конвея стверджує, що архітектура продукту повторюватиме структуру команди. Тож, якщо продукт роблять три команди, то він опиниться з трьома модулями чи сервісами. Цим можна скористатись, щоб передбачити кількість компонент при плануванні.
Вийшов браузер DuckDuckGo для macOS. Він побудований на двигуні WebKit (тобто Safari), та має цікаві функції безпеки. Мені поки власне Safari й вистачає. Єдине, що дійсно визначне в DDG - то урізаний інтерфейс YouTube. Але його нескладно відтворити будь-яким доповненням, що блокує елементи. В мене це давно зроблено через 1Blocker - тобто на YouTube я бачу тільки поточне відео.
Нові версії macOS та iOS виходять у понеділок (у Європі ввечері, спасибі й на тому, що нема спокуси зіпсувати робочий понеділок.) Найбільш очікувана мною фіча — то iCloud Shared Photo Library.
Ще сьогодні збирали всією сімʼєю табурети з IKEA. Тож ділюся статтею по ефект Ікеї. Він полягає в тому, що ми більше цінуємо те, що побудували самі. Це може бути не тільки меблі, а, наприклад, продукт чи сервіс, який хоч і не найкращий, але самописний, тож продовжуємо підтримувати всупереч рації.

Раніше

Пізніше