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

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

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

Раніше

Пізніше

16.10.2023

Глибший погляд в метаданні файлів в Obsidian

Таке тут знайшов… Дивився на зміст структури CachedMetadata заради frontmatter, щоб знайти там jiraQuery. А знайшов, що Obsidian надає доступ до структурного змісту документів.

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

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

Мабуть, деякий розбір все ж доведеться робити (наприклад, Obsidian нічого не знає про мої маркери дат.) Але тут можна або обійтися регулярними виразами, або принаймні розбирати Markdown в межах тексту конкретної задачі.

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

15.10.2023

Глибоке прибирання в Jira

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

Сьогодні накрутив базовий механізм відображення задач з Jira в Obsidian. Як і планував, запит до Jira у вигляді JQL сидить в метаданих до документа. Це надає можливість будувати не один, а скільки потрібно списків задач. Окрім банального списку поточних задач, через JQL можна побудувати списки проблемних задач, які потребують уваги. Наприклад: задачі, які мають змерджений PR, але чомусь не були закриті:

(assignee=currentUser() or creator=currentUser()) and development[pullrequests].all>0 and development[pullrequests].open=0 and status not in (closed, cancelled)

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

Робити пакетні зміни через Obsidian немає сенсу, а от пакетне створення задач, мабуть, так. Мене завжди дратує вносити багато задач в Jira - до кожної доводиться вказувати ті самі атрибути (власника, наприклад). Приємніше підготувати список задач в Markdown, а потім імпортувати (причому проставити автоматично проставити однакові атрибути). Зокрема, так поки плануєш список, можна повертатись до попередніх задач, якщо несподівано змінюється розуміння. Прямо в Jira переробляти вже створені задачі завжди біль.

Так що наступним чином спробую зробити імпортувальник нових задач з Obsidian в Jira.

14.10.2023

Інтеграція Jira в Obsidian

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

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

Проте, якщо потрібно тільки створити список задач на основі Джіри, то можу порадити доповнення Obsidian Agile Task Notes. Тільки мені того не вистачає (та чи здатний я обминути нагоду зробити інтеграцію власноруч?) Тому роблю своє. Хочу на 95% працювати з Jira тільки через Obsidian - в тому числі редагувати.

Поки розповім про дизайн. По-перше, весь сенс існування такого інструменту — це зведення Jira до мінімального потрібного інтерфейсу. Власне витягнути список задач та відобразити його у Markdown - зрозуміло як. З обовʼязкових полів — тільки код задачі — але також, мабуть, треба бачити назву та статус. Причому статус має передаватись як маркер списку, а значить, необхідно спочатку задати переклад статусів з Jira в маркери — бо в кожному проєкті статуси свої.

Звідки задачі брати? На моєму досвіді, краще залишити це на волю користувача та запросити вказати запит JQL для отримання списку. Списків буде більше одного — як я це робив у VS Code. Тому напевно цей запит має бути в метаданих документа; тоді можна скористатись API Obsidian для пошуку всіх документів, в яких встановлений потрібний ключ метаданих, щоб оновлювати в них списки задач.

Як створювати задачі? Логічно, що якщо додаєш в список в Obsidian новий пункт, то він має зʼявитись в Jira. Створити задачу просто, якщо знаєш всі її атрибути (це не тільки назва, але й принаймні проєкт, епік, власник). Що робити, щоб не питати все це кожного разу (окрім, зрозуміло, назви?) Можна прямо в тих самих метаданих поруч з запитом для наповнення списку вказувати набір атрибутів, що будуть призначені новим задачам.

Як редагувати задачі? Тут головна функція — це зміна статусу; далі редагування назви та нотаток. (При проєктуванні треба памʼятати, що для менш частих задач завжди можна скористатися Джірою напряму; а нам важливо не перевантажити інтерфейс.) Зміна статусу — знов через маркери задачі. Редагування назви — хочеться вірити, що вийде (бо щоб отримати назву, доведеться очистити рядок задачі в Markdown від номера задачі та інших атрибутів.) Нотатки — треба дивитись; можливо, вийде розташовувати нотатки як вкладений в задачу зміст Markdown, але це не точно.

Далі буде.

13.10.2023

Огляд навушників JLab JBuds Mini

Отримав навушники JLab JBuds Mini. Їх фішка в тому, що вони надзвичайно малі. Як то кажуть, якби були менші, то митниця б не пропустила як шпигунський інструмент (жартую). Анонс JBuds Mini я побачив в новинах ще минулого року, та вони настільки мені сподобались, що я навіть встановив Google Alert, щоб не пропустити їх випуск.

Як бачите, кейс навушників має розмір та форму великого волоського горіха. Довга сторона приблизно як в кейсу AirPods Pro коротка. А в мене до того були Beats Fit Pro, в яких кейс взагалі дуже великий. (Мікроогляд: BFP це спортивна версія AirPods Pro з ідентичною начинкою, тільки краще сидять та мають фізичну кнопку. Але, наскільки я знаю, в них гірші мікрофони.) JBuds Mini брав саме тому, що їх легше таскати з собою всюди.

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

Базова якість звука десь на рівні Beats Fit Pro, тобто цілком непогано для навушників-затичок, особливо при ціні в $40. Звісно, немає тут ніякого обʼємного звуку, шумозаглушення, голосового виклику Siri, а підключення до пристроїв має форму звичайного Bluetooth Multipoint.

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

Хороші навушники, щоб носити на ключах або не прибирати з рюкзака.

12.10.2023

Що робити, якщо підліток хоче програмувати?

Тільки не пропонувати рідні Ruby on Rails або Go або Java… Мрії підлітків можуть бути різні, але навряд чи це мікросервіс або система бронювання квитків. Скоріше це буде щось візуальне. Гра чи ще щось таке захопливе. Щось круте.

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

Це JavaScript! Причому HTML/CSS я б залишив “на фоні”. На JavaScript можна писати чудові ігри та додатки, які легко перестрибнуть на мобільні пристрої. Для того, щоб ними поділитись, не треба заводити акаунт розробника, та треба нічого встановлювати. До того ж JavaScript працюватиме як на айфоні, так і на андроїді, як на macOS, так і на Windows, тож ніхто не буде обділений. Це прям дуже важливо.

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

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

На таких засадах рекомендую PixiJS. Він як раз підходить під ці вимоги. Можна в одному файлі накрутити просту сцену, а потім потроху доробляти. Середовище розробки може складатися з одного HTML файлу та браузера. Тільки подивіться на цей посібник — саме такий підхід я й мав на увазі.

До речі, щодо поширення - itch.io це туса розробників простих ігор та інших експериментів, де можна й ділитися, й брати натхнення.

Окрема порада — вивчати англійську мову. Зараз діти краще розуміють, що це потрібно. Бо дійсно, без англійської вибір технології звужується до неможливого. Я не уявляю, що навіть порекомендувати. Тож все одно доведеться потроху розбиратися в документації англійською (в мої часи це була довідка по Borland Pascal.)

11.10.2023

Гарна тема — запорука вдалої доповіді

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

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

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

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

10.10.2023

Чому деякі відповіді HTTP в Ruby отримують кодування ASCII-8BIT, а інші — ні

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

Як я писав в минулому, наразі ми майже завжди маємо справу з кодуванням UTF-8, тому важко помітити, що існують інші — принаймні, якщо ми не працюємо з двійковими даними. Так, зазвичай запит Net::HTTP.get() повертає рядок в UTF-8. Оскільки типова вебсторінка має саме це кодування (я навіть не зміг знайти протилежний приклад), то можна подумати, що звідти воно й береться. Але ні — насправді просто береться кодування за замовчуванням в Ruby.

Тому що Ruby взагалі не інтерпретує кодування, яке зазначене в відповіді HTTP. Цього не роблять тому, що інтерпретація не завжди однозначна. Ось обговорення. Є спеціальна опція response_body_encoding, яка або вказує кодування явно, або просить його все ж таки знайти з відповіді. (Або можна просто зробити .force_encoding результату, якщо вже знаєш, що туди передати.)

Звідки все ж таки тоді ASCII-8BIT? На це є точна відповідь. От звідси. А саме: якщо зміст відповіді передається стиснутим, тобто з Content-Encoding: gzip, то вмикається клас Inflater, який примусово перемикає результат в кодування ASCII-8BIT. Бо це є кодуванням для двійкових даних (те ж саме, що Encoding::BINARY.)

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

09.10.2023

Оновлення для Hacker News Feed

Сьогодні зробив два оновлення для своєї стрічки для Hacker News. Стрічка існує з минулого грудня та має своїх користувачів.

Перше оновлення дуже просте — тепер є коротша стрічка https://feeds.leonid.codes/hacker_news_lite.rss. Вона береться тільки з головної сторінки Hacker News та містить від 20 до 30 позицій.

Друге — отримав скарги на те, що стрічка місцями має зіпсоване кодування. Тут вийшло складно. Ну, тобто зрозуміти, що не так не дуже складно — код сторінки в Ruby отримує кодування ASCII-8BIT замість UTF-8, відповідно на виході зайвий раз перекодовується в UTF-8 та при цьому псує типографічні символи.

(Ці символи в оригіналі UTF-8 займають декілька байтів — наприклад em dash це 0xE2 0x80 0x94. Кодування ASCII-8BIT бачить ці байти як 3 різних символи, які поодинці конвертуються в 3 знаки UTF-8, які вже нічого не мають спільного з тире.)

Прямолінійний розвʼязок короткий — зробити документу .force_encoding('UTF-8') та й годі. Але ж мені треба зрозуміти, що є первопричиною. Зрозумів. Про це, мабуть, завтра, бо розʼяснення довге. Поки запрошую підписатись на стрічку Hacker News.

08.10.2023

Типи для представлення масивів даних в JavaScript

07.10.2023

Звідки росте дерево задач?

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

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

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

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

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

Раніше

Пізніше