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

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

06.11.2022

Оновлення блогу - категорії, пейджинація, SEO

🛠️📜🧹 Добре попрацював над блогом.

Розбив всі пости на категорії. Категорії це, на мою думку, найбільш зручний спосіб мандрувати по блогу. Водночас видно, про що я пишу, а про що — ні (наприклад, про Go тільки один пост, хоча здавалося що тем зустрічалось достатньо.)
Викинув теги. Систему тегів важко підтримувати в чистоті. Теги добрі як фолксономія — тобто як колективна категоризація — але для персонального блогу вони тільки додають шуму.
Додав пейджинацію — раніше було ліньки, але ж виводити сотні статей в одну сторінку це неправильно.
Прибрав всі сторінки-переліки з sitemap, та додав їм мітку noindex. Мені здається, це допоможе з SEO. Ці сторінки дублюють зміст самих статей, а тому немає сенсу пропонувати їх пошукачам.
Додав дату останньої зміни у sitemap для постів Стендапу. Розумієте, раніше я брав дату з назви файлу, наприклад 2022-11-06.md. Але Hugo про це нічого не знав, тому в сайтмепі не було дат. А без дат, як мені здається, пошукачі менш пріоритетно ставляться до цих сторінок. Тепер також вказую дату у frontmatter, тобто “нормально”.

До речі, є суттєвий прогрес по відвідуваннях з Google - а саме, з 50 відвідувань в останні місяці показник зріс до 80 відвідувань за жовтень. Це при тому, що до “SEO-покаліпсісу” було 1.5К на місяць.

05.11.2022

Оголошення статті про канал

📢🖼️📑 Сьогодні рівень “мета” досягає нової відмітки. Цей пост - про статтю про канал.

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

Додав пейджинацію замість того, щоб показувати всі пости на одній сторінці.
Додав відображення ілюстрацій до посту. Раніше вони зʼявлялись тільки в телеграмі, бо це не так просто:
Перевірив, що ілюстрації мають зручний розмір як на великому екрані, так і на маленькому.
Налаштував шаблон RSS-стрічки для Стендапу, щоб вона відповідала особливостям структури (наприклад, тих самих ілюстрацій).
Потім, ще й написав статтю з оголошенням, а також більш детальним поясненням, в чому суть цього каналу.

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

04.11.2022

Генерація цифрового календарю відключень

🕑💡🕙 Коли життя дає тобі віялові відключення, час зробити з них цифровий календар.

Для цього достатньо згенерувати файл .ics та завантажити в програму — будь то Calendar.app, Google, або щось інше. Файли ці текстові та не дуже складні та технічно можна друкувати їх звичайним скриптом, без зайвих бібліотек.

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

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

03.11.2022

Огляд додатків карт, якими я користуюсь

🗺️📍🧭 Сьогодні весь день за кермом, тож замість коду розповім про карти. Картографія — моє маленьке хобі. Зроблю короткий огляд додатків, якими постійно користуюсь.

Apple Maps - карти за замовчуванням. В Україні не те щоб в них погана карта (бо вона від TomTom, це одна з найкращих карт), але їм просто не вистачає полірування. Добре, що вони є, але я майже ніколи їх не відкриваю.

Google Maps - справжні карти за замовчуванням (навіть в DuckDuckGo за ключем !map). Добрі й для навігації, і для пошуку обʼєктів (особливо корисним є те, що вони підсвічують цікаві райони жовтим). Що тут казати, немає нічого кращого. В загальному плані.

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

Organic Maps - найкращий клієнт OpenStreetMap. Це гілка додатка Maps.me, яка має відкритий код, та не має трекерів. Бо Maps.me колись купив мейлру, і після цього я був вимушений припинити їм користуватись, хоча програма дуже зручна, особливо в подорожах, бо зберігає повний функціонал без інтернету. Їй навіть можна користуватись для автонавігації та навіть через CarPlay.

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

02.11.2022

Тип "дата" та його відсутність у різних мовах програмування

📆⏱️🙅‍♂️ Просуваюсь з HealthKit проєктом. Черговий раз стикаюсь з відсутністю типу даних для календарного дня, на цей раз у Swift. Поки терплю.

В чому моя проблема? Найбільш звичайний часовий тип в мовах програмування відповідає моменту часу. Навіть якщо при цьому називається Date. Так само в JavaScript та в Golang. Це добре, якщо ваша логіка працює з моментами, або довільними проміжками часу.

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

Наприклад: будь-які підписки робляться в днях, а ніяк не в секундах чи іншому. Звісно, можна перекласти це на проміжки часу (та й всі так роблять), але потрібно завжди памʼятати, які операції безпечні, а де треба проконтролювати; можливо, пильнувати за тим, щоб кожне значення було початком дня — але це теж не панацея.

Ось в Ruby є окремий тип Date і це чудово. Для JavaScript я зробив бібліотеку dayjs-date. А у Swift поки нічого не знаю, роблю як є.

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

01.11.2022

Организація нотатків у Obsidian

🪨📂🧊 Продовжуючи тему з Obsidian: для системи, що працює з простими файлами, можливостей організації тут багато.

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

Крім того, я створив теки для: проєктів; робочих нотаток; довідкових матеріалів; чернеток. Все це вже було в моїй базі нотаток, але без доброї організації. Раніше я спирався на теги, які в Obsidian, звісно, також є.

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

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

Відкриття дня — гра Frostpunk. Атмосферна стратегія про виживання міста у льодяній пустелі. Йде і на macOS, а ще зараз зі знижкою.

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, бо не дає іншим членам команди використати свої знання. Тому краще питати публічно, навіть якщо здається, що відповідь знає хтось конкретний.
Обговорення. Ніхто ніколи не тримає весь контекст проєкту водночас, тому завжди є шанс, що дехто з команди відкриє ще невідомий бік питання. Також обговорення в спільному чаті роблять рішення відомими всім та відразу. Якщо ж обговорювати приватно, то хибні рішення будуть помічені пізніше і коштуватимуть дорожче.
Історія. Зміст публічного чату можна знайти пізніше. Є питання та ситуації, що виникають знову і знову. Так, ідеально було б задокументувати кожне, але я не вірю, що хтось так робить. Але якщо просто обговорювати публічно, то журнал чату — це вже документація. Я часто шукаю (та знаходжу!) висновки з обговорень, зроблених рік чи більше тому. Звісно, документацію це не скасовує. Наприклад, розвʼязок кейсів підтримки можна почати в чаті, а потім перенести в повноцінну базу знань.

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

Раніше

Пізніше