Трохи про доведення справ до кінця.

Я вже якось згадував, що покладаюся на три тести для оцінки себе. Про один (від компанії Рея Даліо) я написав ще тоді, а зараз зʼявився привід згадати ще один: 16personalities. Насправді це безплатна і трохи простіша версія тесту Маєрс-Бріґс (на який Рей Даліо теж посилався), розробленого дочкою-психологинею та її матірʼю під натхненням від книги Карла Юнґа «Психологічні типи».

Тест дає на диво точні результати, але мова не про те. Я проходив його тричі: у 2018, 2020 та 2023. І перші два рази отримував INTP-A профіль, який вони називають Assertive Logician. А ось останній раз показники незначним чином змінилися, і я «став» ISTP-A, або Assertive Virtuoso. Головна зміна відбулася в другому параметрі, як можна побачити по літерах, тобто на шкалі від N (iNtuition) до S (obServation or Sensing). У 2018 я начебто покладався на інтуїцію на 67%, у 2020 — лише на 52%, а у 2023 всього на 48% (тобто тепер став на 52% спостережливим 🧐).

Все це схоже на маячню, проте я зауважив, що приблизно в той самий час я став доводити до кінця деякі свої ініціативи: почав і дописав невеличку бібліотеку для QML разом з детальною документацією, якісь там модулі десь, трохи поконтрібʼютив в опенсорс… та навіть полички в хаті понавішував!

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

«How you do anything is how you do everything»

(сама фраза походить чи то з дзен-буддизму, чи хтозна-звідки ще).

Поміркувавши, я зрозумів, що мій підхід до ігор завжди був приблизно такий: раз в ніколи я сідаю за компʼютерну гру, граю в неї майже цілодобово, і десь годин за 30–35 мене відвертає. Тож якщо гра коротка, я її встигаю пройти, а якщо ні, то просто кидаю. Цікаво, що свої пет-проєкти я зазвичай робив так само!

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

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

Back to present day. Я пройшов свою нині улюблену гру Mass Effect (200 годин), я пройшов Baldur's Gate 3 (300 годин), у мене є як робочі, так і особисті ініціативи та проєкти, які хоч і неквапливо, але все ж просуваються впродовж доволі тривалого часу. Всі ці штуки поєднує той факт, що я більше не намагаюся подолати їх ривком — натомість я спокійно планую, а потім крок за кроком виконую.

Якщо я вам просто скажу: «start small, stay consistent» — це не допоможе. Тобто звісно саме так робити і треба, але… як себе змусити?

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

Отож, підсумки не підбиваю. Кидайте свої результати тестів у коментарі.

Є у мене в домашній мережі купа self-hosted сервісів, значить. Більшість у докері. А проблема з докером у тому, що він порти на хостовій машині займає, так їх ще й памʼятати треба (або записувати кудись). І якось не прикольно потім у браузері писати та бачити http://myserver:53412.

Як сервер у мене Synology NAS наразі, і там є вбудований реверс-проксі. Цього було б достатньо, щоб зробити собі адреси виду http://myserver/gitlab, але хочеться радше http://gitlab.mynetwork. Тож підняв я додатково DNS-сервер (також від Synology, хоча там, мабуть, тільки юайка їхня) і зрозумів, що це дуже прям запарно налаштовувати тепер. Доводиться в декількох місцях одне й те саме прописувати.

Виявилося, що замість повноцінного DNS-сервера в локальній мережі можна використовувати mDNS, проте, з ним також є певні проблеми. А для більш-менш автоматичного налаштування реверс-проксі можна було б перейти на Træfik чи Caddy. Та це вже якось вище мого порога заморочливості.

Тож я здався та спробував Tailscale. Це така штука, яка дозволяє дуже легко та швидко побудувати свою VPN.

Ідея звісно не нова: ще на початку 2000-х ми з друганами думали, як нам грати разом в ігри, якщо ми живемо в різних районах. У першому StarCraft можна було, наприклад, зателефонувати модемом напряму модему другана, прикиньте ☎️ Але то поодинокий випадок скоріш. А ось десь у 2004-му зʼявилася така славнозвісна в ті часи прога як Hamachi (на скріншоті саме вона). Вона дозволяла змусити ігри думати, що два віддалених компи насправді в одній локалці — те що треба!

Зараз такі штуки теж існують. Наприклад, ZeroTier. Ми з ексколегою намагалися через нього пограти віддалено в Cuphead, але воно зрідка давало неприємний лаг. (Ми з ним пограли врешті, але інакше).

Так ось, а шо Tailscale? Ну більшість з вас, мабуть, вже й так в курсі — це тільки я слоупок. Але фактично це те саме, тільки на базі (дуже швидкого) протоколу WireGuard, й до того ж підтримує меш-мережу.

Цікаве тут інше: tailscale можна підіймати прямо в докер-контейнері, фактично додаючи його у вашу мережу як окрему машину. Тобто виходить наче у вас є окремий комп, на якому стоїть тільки той сервіс, який ви там підняли. Отож з суботи я займався міграцією деяких штук у свій новий tailnet.

В принципі, процес доволі straight-forward. Налаштував собі простий GitOps для автоматичного деплоя ACLs та docker-compose.yaml файлів. Наче норм.

Але зʼявилася зворотна проблема: не всі сервіси легко підіймаються на 80-му порту 😤 Це тому, що перші 1024 порти привілейовані, й вішатись на них можуть тільки проги з відповідними правами. Однією з неспроможних штук виявився форк Gitea — Forgejo, який я вирішив собі підняти замість GitLab (бо останній заважкий для моїх потреб). Танцював навколо нього майже дві доби, але так і не зміг змусити його забайндити на себе 80-й порт. Зрештою довелося в контейнері ще підіймати nginx чисто заради цього.

Запрацювало тепер-то! Можу відкривати http://git/ та насолоджуватися 😎 (причому навіть не вдома, бо у мене навіть на телефоні Tailscale).

Цікаво до речі, що сучасні програми вкрай кепсько реагують на подібні короткі адреси: телеграм не запарсив як URL (з міркувань безпеки, я думаю), браузери постійно намагаються відкрити мені пошук замість сайту, а Arc навіть не зміг зберегти закладку 🤡 Я не кажу вже про http (без s). Але це вже інша історія.

Обожнюю отримувати такі автоматизовані листи з систем наших клієнтів 🥸😅

Як же складно (і прикольно) мати свій домашній сервачок, жах!

В принципі Tailscale справді дещо спростив. Але пару додаткових днів я все-таки вбив: то зовнішні адреси не пінгуються, а тільки адреси з tailnet, то навпаки, то і ті, й інші відвалилися, то на хостовій системі ок, а в контейнері адреси не резолвляться, то контейнери з restart: always не рестартують (до речі хз чого). Ну а зрештою взагалі випадково вбив свій інстанс ґітлабу, тому що запустив два контейнери, обидва з яких писали в одну теку.

Tailscale зручний, та все ж далекий від ідеалу. Наприклад, на macOS у них аж три різні офіційно підтримувані версії з різним набором фічей, а на моєму Synology він працює з низкою обмежень. (До речі в обох випадках головна завада — системний сендбоксинг). Одначе користуватися цим можна.

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

У попередньому дописі я згадував Tailscale мого дитинства — Hamachi. І знаєте, що з ним трапилося? Він перетворився на лайно 💩 Сталося це в ту мить, коли його купила угорська компанія 3am Labs, яка згодом стала називатися LogMeIn, яка до речі пізніше купила й LastPass, а ще пізніше злилася з дочірньою компанією Citrix, що робила GoToMeeting та інші продукти з тієї ж серії, тож зараз вона так і називається — GoTo. Якщо ви колись користувалися LastPass (у яких вже регулярно крадуть користувацькі дані), «новим» Hamachi або GoTo Meeting, то нескладно помітити коричневу марку якості.

Як же себе захистити від подібного з Tailscale? Ну, на щастя їхній демон та CLI-клієнт — повністю open-source. Сервер ні, проте, вони не забороняють використовувати якийсь свій, тож це було питанням часу, коли хтось напише власний. Чекати довго не знадобилося: наразі існує доволі фічастий Headscale. Тож виходить, що в принципі можна все потрібне заселфхостити.

Що саме Tailscale дає особисто мені? Ну, декілька речей:
• легке налаштування віддаленого доступу до якихось селф-хостед речей без необхідності випускати їх в публічний інтернет. Тобто не треба прокидати порти кудись назовні, морочити голову з DNS або DDNS тощо, а потім трястися, що хтось підбере твій qwerty123. У мене серед таких речей мій ґіт-сервак, книжки, скани документів, база хавки, Home-Assistant і т.д.
• легша взаємодія зовнішніх сервісів (low-code платформи для автоматизації або тих же GitHub Actions) з цими внутрішніми штуками. Робиться це завдяки ефемерним ключам, наприклад: у вас на раннері запускається пайплайн, авторизується в tailnet (з відповідними правами), спілкується з потрібною нодою, а потім видаляється з мережі щойно йде офлайн (в кінці workflow).
• швидке перекидання файлів між пристроями а ля AirDrop.

Поки це всі юзкейси, може згодом ще щось знайду. А зараз відчуваю, що досить — моя devops-чаша вже переповнена ))

Кому взагалі здалося хорошою ідеєю робити stretch для зображень? Хіба це має сенс бодай колись? Фігачнув собі “Arc Boost” (нормальні люди називають це UserCSS) для нещодавно встановленого Calibre-Web, бо не було сил терпіти це.

Код виглядає отак:

.container-fluid .book .cover span img {
  height: unset !important;
  max-height: 100%;
  position: absolute !important;
  bottom: 0;
}

Моє знання CSS наближається до 0, тож я попросив ШІ-шку це зробити (Claude 3.5 Sonnet норм), а потім перебором додавав !important, доки воно не запрацювало.

Не знаю, як вам, а мені обкладинки трохи різних розмірів муляють око значно менше, ніж розтягнуте зображення.

Втім загалом враження від Calibre-Web радше негативне. Це зовсім не «plex для книжок», як я розраховував. Найбільше мені сподобалося, коли я натиснув кнопку, щоб стягнути для книги метадані з інтернету, воно наче щось знайшло, перемістило файл в іншу теку, а БД чогось оновити не змогло, і просто роллбекнуло транзакцію 🤷🏻‍♂️ Тож база розійшлася з файлухою у перші ж 20 хвилин користування ))

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

«Якщо у вас є окремо база та окремо файли, то це питання часу, коли трапиться розсинхрон»

— тож він просто складає все у Postgres. І капе-е-е-ець, з одного боку звучить логічно, а з іншого боку — ну дуже лячно! 😬 Бо якщо база якось покораптилася, то у першому випадку хоча б файли лишаються, а у другому — скоріш за все «це кінець». Ви як би робили, якби оригіналів документів у вас не лишилося?

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

Проте ні, правило максимально просте:

Якщо користувач щось зробив, програма мусить це запамʼятати.

Ну тобто мова про збереження стану загалом, так. Щоразу, як вас змушують повторно заповнювати форму, знов скролити до місця, на якому ви припинили читати, або навіть просто знов логінитися — це кепський UX.

Але найбільше мене тіпає, коли ти вводиш якийсь текст, а програма його після певних дій втрачає 🤬 Повна зневага до часу користувача та до виконаної ним роботи.

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

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

Просто не передавайте фокус в інший контрол на release event, м? Робіть це тільки на press. Як вам така ідея?

C++-комітет продовжує підглядати в спеку Haskell обговорювати нові потенційні фічі для мови. Цього разу (документу вже рік насправді) дійшло до плейсголдерів _, щоб зручно було користуватися зіставленням із взірцем (паттерн-матчінгом), якого звісно досі нема, або, наприклад, розпаковувати кортежі на кшталт:

auto [x, y, _] = f();

Тут типу третє значення нам не суттєве, тож можна використати _, щоб не вигадувати імʼя, а потім боротися з ворнінгами про те, що воно не використовується, додаючи [[maybe_unused]].

Та C++ би не був собою, якби все було так прозоро. Ніщо не заважає вам і зараз використати _ як імʼя змінної:

auto [x, _] = make_pair(1, 2);
cout << x << "," << _ << endl;  // використання

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

auto [x, _] = make_pair(1, 2);
auto [_, y] = make_pair(3, 4);

Зараз такий код генерує error: conflicting declaration ‘auto _’, бо це повторна декларація змінної, а от з новим пропоузалом перестане.

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

auto _ = 42; // Оголошення
auto _ = 0;  // Повторне оголошення
{
    auto _ = 1; // Новий скоуп. Оголошення з шадовінгом
    assert( _ == 1 ); // Можна прочитати
}
assert( _ == 42 ); // Не можна прочитати 🙂

В принципі, очевидно, еге ж?) А, до речі… У неймспейсі двічі не можна оголосити:

namespace a {
    auto _ = f();  // Ок
    auto _ = f();  // Помилка
}

Все логічно, короч 🤡 Ні, заждіть, це не жарт. Все справді логічно, якщо над цим поміркувати достатньо довго! Але капець, як же втомлює тримати подібні нюанси в голові весь час.

З іншого боку шанси, що це увійде в C++26, все одно низькі ) Може в C++32…

Взяв я собі ж R1, як вже згадував. Тижні три чи чотири лежав у мене — ліньки було розпаковувати.

Відтоді, як я його замовив, в інтернетах вже зʼявився 1000001 відос про те, який це скам. І скоріш за все так воно і є. Та я не жалкую, бо разом з ним я отримав річну передплату на Perplexity (власне, за ціною річної передплати). Тож сприймаю це як безплатний пристрій 😅

Що сказати по самому девайсу… Пластик відчувається якимсь дешевим, але загалом пристрій дуже solid. Українською запити ігнорує, але коли просиш перекласти щось з української іншою мовою — робить це без проблем. Концептуально дуже схоже на кишенькову Amazon Alexa, тільки розумнішу й водночас менш спроможну. Alexa хоча б світло може вимкнути 😁

З інтеграцій є тільки Spotify/Apple Music, Uber, DoorDash, Midjorney та Suno. Я ще не настільки сказився, щоб логінитися під своїми акаунтами на чиїхось ремоут-компах, тож протестувати, мабуть, не вийде. Та й нагадую, що їхня хвалена LAM (Large Action Model) наразі виявилася пачкою кривих скриптів під Playwright.

Ютубери та інші тиктокери вже так затролили їхню ШІ-шку, що коли показуєш Реббіту в камеру коробку від харчової добавки, що ветеринар виписав коту, й просиш розказати, що це, воно замість інформації видає текст на хвилину про те, чому воно не може давати мені медичні поради, і як це все небезпечно, і наскільки воно відповідальне і т.д. Доволі useless короч.

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

Після вчорашніх всесвітніх забавок через CrowdStrike це було питанням часу, коли знов почнуть парити про memory safety звідусіль.

І справді, наразі найбільш помітні та водночас підозрілі факти — це забитий нулями sys-файл драйвера та спроба звернутися до памʼяті через null-вказівник. Про друге я додам від себе «пару» слів.

Навіть якщо тред не дочитали, у вас, мабуть, все одно промайнула думка, мовляв, треба було на #Rust писати — там-то таке не могло трапитися, бо «Rust же — МЕМОРІ-СЕЙФ!!!11», не те що ваш C++.

Теза перша:

Безпека доступу до памʼяті — не єдине, про що треба подбати.

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

Теза друга:

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

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

У моєму дитинстві у нас в хаті були спеціальні пластикові заглушки в розетках «від/для дітей». І знаєте що? Це не спинило малого мене перевірити, що буде, якщо встромити в розетку довгогубці, які так чудово пасували під два отвори. Інструмент (заглушки) був, а дисципліни бракувало.

Теза третя:

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

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

Або ножі… Ух, це просто протилежність слова «безпечний», і все ж в кожній хаті є щонайменше декілька. Навіть якщо у вас є безпечніша нарізна машина (блендер якийсь абощо), то й звичайні ножі все одно також.

Або варильні поверхні. Ось тут прям прогрес помітний. В дитинстві у більшості газові були. Та й досі є, але я вже років 10 не користувався. Є резистивні електричні. Вони не тільки безпечніші, бо немає відкритого полумʼя або можливості лишити відкритим газ, так у них і ККД більше. А ще є індукційні, які на жаль потребують особливого посуду, але натомість отримуємо миттєвий нагрів, ККД на рівні 90%, неможливість ввімкнути порожню тощо. При цьому місця займає стільки ж, перенавчатися для користування не треба. Оце я розумію — покращення!

Повертаючись до null-поїнтерів… Я великий шанувальник кращих інструментів. Коли я бачу щось, що будь-яким чином покращує мені роботу чи життя — я, не вагаючись, починаю цим користуватися.

Та не буває нічого безпечного на 100%. Всі інструменти небезпечні до певної міри. Просто вчіться, бляха, ними користуватися!

У сучасному C++ писати raw-вказівники взагалі вважається ганьбою, тому що вже існує купа засобів та методів програмувати цією мовою на порядок безпечніше.

І Rust міг би бути інструментом, що ще більше поліпшує життя програмістам, та я не бачу, щоб він ним справді був. Конкретно в цій ситуації з null-поїнтером Rust може й справді б зарадив, але в численних інших — ні, а у деяких випадках може й інші проблеми б приніс. Та в будь-яких розмовах на цю тему мова C++ — це завжди щось чорне-чорне, суцільне зло, винахід диявола, небезпека небезпек, а Rust — це завжди порятунок, манна небесна, silver bullet та ложка з «Матриці». Ні! Заїбало.

Звинуватити C++ легко. Але скажіть мені краще, як так вийшло, що 45-кілобайтний sys-файл був забитий нулями, і це потрапило в реліз. Де дисципліна, Лебовскі?

Ніхто не вміє робити теги правильно. І я теж, але обговорімо.

Взяти, наприклад, Paperless. Це така система для керування та пошуку по відсканованим документам. Автори кажуть: «теки ми не зробили, бо є теги». Типу, хочеш згрупувати декілька елементів — використовуй тег. І в принципі норм, а шо, хоча відчувається якось неприродно час від часу.

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

Та з ієрархією неодмінно настане момент, коли не зрозуміло, в яке місце додавати новий елемент, а дублікати створювати не хочеться. Ось є у мене ієрархія тек по мовах програмування: ну, там… C++, Haskell, JavaScript, Red тощо. І тут я хочу зберегти посилання на бібліотеку Slint, яка є і для C++, і для Rust. Тож в яку теку її додавати? Або, уявімо, що теки були не по мовах, а по категоріях: DB, Network, UI й т.і. Тоді куди тут додавати Qt, якщо він чудово справляється з усіма ними? Ну ви зрозуміли. У такому випадку зазвичай як раз достатньо обрати якийсь один варіант для утворення ієрархії, але для пошуку всі характеристики краще перелічити як теги.

Тут виникає інша проблема. Якихось характеристик, властивих поточному обʼєкту може бути ну дуже багато! І ніколи не знаєш, які треба додати, а які не обовʼязкові — дізнаєшся це, вже коли намагаєшся знайти щось, і не виходить 😖 Одного разу я автоматизував собі додавання усього, на що я ставлю зірочку на ґітгабі, у Raindrop зі збереженням тегів. І тепер у мене 2500+ тегів, з яких, мабуть, 80% зустрічається в _одиничному_ екземплярі серед усіх 1600+ закладок. Бо люди на ґітгабі теж не знали, які теги варто додати, а які ні.

Або ще проблема. Ось є у мене в закладках якісь відеоредактори: чи має бути тег #відеоредактор, чи все ж #відео та #редактор? Чи може всі три одночасно?

А ще дратує, коли якісь суто технічні обмеження для тегів створюють: тільки маленькі літери, без пробілів, без дефіса, без інших символів тощо. А якщо немає цих обмежень, то теж погано: починаєш думати, чи маленькими літерами все писати, чи великими? Має бути #javascript чи #JavaScript, чи може #js або #JS?

Obsidian, в якому я це пишу, пішов далі й дозволив ієрархічні теги. Це в принципі вирішує низку проблем. Наприклад, я можу створити тег #редактор/відео і швидко знайти саме відеоредактори, але також можу і побачити взагалі всі (уявімо, що там текстові, аудіо-, графічні й т.і.), якщо шукатиму чисто по #редактор. Зручно? Зручно.

А втім… Зваживши все, що я написав раніше, чи бачите ви проблему?

Саме так! Це ж та сама ієрархія, але вже серед тегів. Тобто й обмеження, й решта проблем всі ті ж самі. Візьмемо #arduino, наприклад. Куди його покласти: в #залізо чи у #бібліотека для C++? Адже насправді воно і те, й інше.

Тож вже напрошується єдиний правильний висновок: треба дати можливість тегати теги!

І тоді при пошуку можна буде брати як той тег, що безпосередньо був обраний користувачем, так і теги, які йому належать. Якщо ви шукаєте щось по тегу #залізо, то ймовірно хочете побачити там і те, що стосується #arduino. Якщо у вас є тег #FreeRTOS, то він сам може бути протеганий як #Amazon, #real time, #MIT license, тоді як #real time стосуватиметься #operating system, а #MIT license належатиме до #open source. Тоді шукаючи за тегом #Amazon ви автоматично знайдете все, що цим тегом явно позначено не було, але було позначено як #FreeRTOS.

Звісно, є й зворотна сторона. Наприклад, ви шукаєте #open source, і воно, розмотуючи ланцюг, знаходить тег #FreeRTOS, яким ви позначили щось, що стосується FreeRTOS, але само по собі при цьому зовсім не обовʼязково open source.

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

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

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

Наразі вже певний час триває (повторний) розквіт механічних клавіатур, який для мене особисто почався більше 10 років тому з купівлею клавіатури на Cherry MX Blue. У ті часи перемикачів в принципі було 4 доступних: сині, коричневі, чорні та червоні. Ще пара людей могла щось чути про Topre, та то скоріш виключення. Зараз же перемикачів існують сотні: ті, що клікають при натисканні, ті, де відчувається «сходинка», лінійні, тихі та не дуже, з різним зусиллям, від різних виробників, побудовані за різними принципами тощо. Зʼявляються регулярні порівняння, відбуваються холівори, та довгий час незмінним лишався один факт: перемикач лишався просто перемикачем — тупо boolean ввімкнено/вимкнено. Решта вже снобізм та смаки, як на мене. (У мене до речі Gazzew Boba U4, якщо це комусь про щось скаже. Мій вердикт — норм 🙂).

На моєму обрії все змінилося, коли на кікстартер вийшла Wooting зі своєю клавіатурою one. Сама по собі вона була не надто цікава на відміну від оптичних перемикачів, на яких вона базувалася. Оптика дозволила не просто реєструвати факт натискання, а реагувати на глибину. Я сам граю майже виключно іксбоксовим геймпадом 🎮, тож для мене цілком нормально контролювати в іграх дії, як-от швидкість руху, дуже точно, не кажучи вже про можливість відчувати те, що відбувається на екрані, завдяки haptic feedback. І це сильно відрізняється від досвіду гравців на клавіатурі та миші, де ти ніби перебуваєш у пласкому цифровому світі — наче деякі відчуття заблокували. (Але у людей там свій фан, не будемо кейборд-шеймити тут 😂).

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

Чого здатність повільно ходити в грі не може зробити, так це продати комусь клавіатуру. Тому Wooting вигадала невеличку оптимізацію під назвою Rapid Trigger, яка потенційно давала відчутну перевагу у змагальних іграх. Ідея у тому, що замість перемикання у якійсь конкретній точці світч реагує на зміну напряму руху. Іншими словами, ви натиснули кнопку, й щойно почали її відпускати, як клавіатура перестала слати для неї івенти. Якщо знов донизу пішло, знов надіслали. Це дозволяє ніколи не натискати та не відпускати кнопку до кінця, що стає в пригоді в іграх. Razer, SteelSeries та інші теж «надихнулися» та зробили у своїх пристроях таке.

Wooting пішла ще далі. По-перше, виявилося, що оптичні сенсори не дуже точні при максимальному натисканні. А по-друге, вони… бруднилися 🚯 Тож компанія перейшла на сенсори на ефекті Холла. Але цікавішою була їхня подальша оптимізація Rapid Trigger, яку вони назвали Rappy Snappy. Тут вже стало очевидно, що цільова авдиторія — це саме геймери. Короч, ідея у тому, що можна повʼязати дві кнопки з «протилежними» діями, наприклад, вліво/вправо або вгору/вниз, та реєструвати натискання тільки однієї з них — тієї, що натиснута глибше — бо мати їх обидві одночасно натиснутими все одно несе небагато сенсу в більшості ігор (бо у такому випадку гра зазвичай ігнорує обидві).

І ось не так давно Razer відповіла на це власною варіацією під назвою Snap Tap. Замість того, щоб покладатися на те, наскільки глибоко кнопки натиснуті, вони реагують на останню зміну стану (натискання/відпускання). Таким чином можна, наприклад, тримати одну кнопку завжди натиснутою, а іншою змінювати напрям руху.

Що там ще цікавого навигадували? Хтось в темі?

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

Тут чувак у сусідньому каналі (Я вже рекомендував? Рекомендую!) пише, мовляв, подивіться, як програмували у 90-х… скільки коду треба було написати, щоб зробити просту програму.

Ну, я подивився. А там приблизно те саме, що я й зараз пишу 😅😭 Тільки розмірність вікон та координати значно менші )

Щось десь краєм вуха чув про GraalVM, але сильно не цікавився. Виявляється, можна нині скомпілювати джаву в нативний бінарь без JVM, і це дає реальний приріст як по CPU, так і по пам'яті 👇