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

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

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

Раніше

Пізніше

17.10.2023

Нова система. Homebrew Cask. Dev containers

Сьогодні налаштовував новий компʼютер для роботи. Це мій перший компʼютер “тільки для роботи” років за… пʼятнадцять, напевно. Як писав, це для того, щоб на роботі було менше відволікань, а з іншого боку — можна було фізично припинити працювати та все ж не залишитись без компʼютера як засобу для спілкування, хобі та розваг. (Мініогляд: обрав Mac Mini, бо давно було цікаво, але ніколи раніше не було підстави його мати. Це найнудніший з маків — просто коробка з macOS. Він більше та важче, ніж я уявляв — майже з Macbook Air завширшки. Зате блоку живлення немає — тільки тонесенький кабель. Ось… більше немає що про нього казати.)

Вперше спробував Homebrew Cask та я в захваті. Це доповнення для встановлення звичайних додатків через Homebrew. Без перебільшень, всі програми, які мені були потрібні, вдалося там знайти. Тобто замість пошуків на сайтах, завантаження і так далі можна просто зробити brew install visual-studio-code firefox setapp і так далі. Ба більше, так само можна встановити й шрифти. Єдине, що я встановлював не через Cask - це додатки з Setapp (в ідеалі вони б теж могли мати CLI, але поки не бачу.)

Для того, щоб почати використовувати Homebrew Cask, не потрібно перевстановлювати систему, тож раджу випробувати — воно того варте.

Друге, що випробував — це Development containers, відносно новий механізм для розробки прямо в Докері. Пропозиція така: не потрібно буде нічого встановлювати локально, тільки Docker та Visual Studio Code. Все інше — в контейнері. Причому робоча частина VSCode теж працюватиме з контейнера та матиме доступ до всіх інструментів.

Так розвʼязуються дві задачі. Перша — уникнути складного налаштування середовища на локальній машині (але це більш актуально для Windows.) Друга — надати можливість поділитися середовищем з командою. Тут допоможуть такі функції, як Features - типу “пакети” з утилітами, та можливість вказати, які доповнення VSCode встановити в контейнері. В теорії, все це значить, що від клонування репозиторію до повноцінної розробки у нового члена команди буде достатньо відкрити VSCode та почекати, поки все розгорнеться.

Зазначу, що dev container - це не те ж саме, що конфігурація docker compose для локального запуску додатка. Dev container утворює середовище для запуску будь-яких команд в проєкті — від сервера чи тестів до лінтерів, Git та, звісно, самого VSCode. Dev container спирається на Docker Compose, наприклад, щоб створити бази даних та інші потрібні сервіси.

Це все добре, але насправді девконтейнер в мене не прижився через відсутність інтеграції з 1Password CLI. Так, технічно встановити CLI в контейнер можна. Але з точки зору 1Password це буде окремий компʼютер. Нормального способу передавати секрети в контейнер я не знайшов. (Наприклад, передавати в змінних оточення на весь час існування контейнера мене не влаштовує.) Можливо, якісь обхідні шляхи можна було знайти, але не настільки ті девконтейнери мені зараз потрібні.

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

Раніше

Пізніше