Написав статтю місяць тому і забув опублікувати, це капець. :) Кароч історія в тому, що показування HTML'ю користувачу після того, як він нажав кнопку "назад" - це не дуже тривіальна операція. З реактом історія була у тому, щоб заново відрендерити йому те, на що урл вказує, а без реакту... без реакту можна або зберігати верстку десь, або заново ходити на сервер. Друге робить HTMx, а перше робить TwinSpark: https://solovyov.net/blog/2021/history-snapshotting-in-twinspark-js/

Слухайте, провтикав взагалі написати, я пішов сьогодні в гості на стрім до Вови Рожкова @full_of_hatred. Тож якщо вам сьогодні ввечері немає чого робити, через 7 хвилинок ось тут: https://www.youtube.com/watch?v=2gwt1T9DjGk

Ось обговорювали с Вовою, чому ж Дія Сіті — це погано. Мої думки про це ось такі:

1) Інженерно вони дуже слабкі. Дія, як аппка, дуже погано працює: то є там мої права, то немає, тупо час від часу як повезе. Розлогінює часто.
2) Продуктовий віжн в них поганий. Він може і сильний, але поганий, тому що роблять вони централізованний реєстр документів, який дуже вразливий до корупції та кібер-атак. Нам, як країні, треба навпаки. От ID-картки в цілому у вірному напрямку рухалися, а єдиний реєстр — це дуже-дуже погано. Якщо хочете дізнатися наочно чому — подивіться на ютубі розслідування Навального про те, хто його травив.
3) Менеджмент в них дуже поганий. На надзвичайно тупу і надзвичайно небезпечну дірку вони відреагували максимально тупо: мовчанням. Це просто неприпустимо для будь-якої публічної компанії, я вже не кажу про державі установи.
4) Все, що робиться за кошти громадян для країни, повинно робитись з відкритим кодом з відкритою ліцензією. Тому що, по-перше, це наш софт, ми за нього заплатили, і не треба його від нас ховати. По-друге, це справа національної безпеки: мати не security through obscurity, а публічний контроль цієї самої безпечності ПО.

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

Така цікава тема в мене є... який геній займається проектуванням кімнат в готелях, цікаво? Ось маємо двокімнатний номер, в ньому, вочевидь, є міні-бар, який зроблений з маленького холодильничку, що вбудований у «робочий» стіл — бо безпонтово його окремо тримати, це ж напівлюкс (або люкс, я заплутався вже).

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

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

Так ось питання таке: нашо в номері за такі гроші така прикольна економія на кулері? І якого перцю той мінібар у спальні, якщо вже є дві кімнати?!

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

Понабирають студентів по 5$/година, а потім результати проектування як люкси здають, ггг :)

Кілька днів провели сім‘єю в Одесі і дуже мене неприємно вразила кількість реклами і оголошень російською мовою, наче у 90-ті повернувся. Тобто Київ не те що б україномовним мені відчувався, але майже вся реклама українською, на моє відчуття, 70% кур‘єрів та менеджерів та взагалі сфери обслуговування починають розмову українською, а більшість інших переходить на українську після перших моїх слів. І взагалі, я якось зібрав булки у кулак і з незнайомими людьми вже майже завжди українською спілкуюся. :)

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

Тож до чого це я. Думаю що піду зара вб‘ю російську клаву в айфоні і подивлюся, де буде важко жити. :) І Одесу ніхто у Коцюбіїв не перейменує назад, але, маю надію, що хоча б мовні закони відміняти не будуть.

Доволі цікаво, як Епл використала один і той самий процесор у зовсім різних сегментах. І мак міні за 700$, і айпад про за 800$, і ноути трішки дорожче тисячі, і аймаки за 1700$ - всюди один і той самий проц (тільки іноді без одного перформанс-ядра у відяхи). Це типу з однієї сторони він енергоефективний (тож підходить айпадам), з іншої - достатньо швидкий, щоб продавати девайси за півтори тисячі і не боятися порівнянь з x86.

Прикольно, насправді. Я не передивлявся ретельно тестів та й не занурювався у подробиці, але на власних відчуттях так воно і є: ейр м1 з однієї сторони живе майже як айпад про наш (якому 4 роки напевно зараз), з іншої — він помітно швидший за мій попередній macbook pro. Much snappier UI, щоб розмовляти усталими термінами. ;) Я б навіть сказав, що відчуття від швидкості реакцій інтерфейсу не гірші, ніж у вінди на райзені — а вона завжди кращє макосі була з точки зору затримок в юаї.

Тож виглядає що епл нормально так попала. Зрозуміло, що то не овернайт саксес і вони його будували 12 років — у 2008 якось вмовили Джима Келлера приєднатися до Епла і купили згодом P.A. Semi, де він працював до того. Того самого Келлера, що автор Атлону64 і Райзенів!

Тож дуже цікаво, що там епл випустить далі! З ядрами наче зрозуміло, клепайте більші (і дорожчі) проци і буде більше ядер. А от з пам’яттю... мак про зара може мати до 1.5 терабайту озу, а з тою архітектурою пам‘яті, що є зараз, це буде нереально дорого. Перейдуть на DDR, як в усіх? Не знаю, але здається, що далі буде ще прикольніше. :)

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

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

Але ж виконати x = 1 + 2; y = x + 1 за один такт неможливо, бо y залежить від x. Через це процесори всередині змінюють порядок інструкцій, щоб мати змогу використовувати свої непересічні здібності. Тож ефективність процесору дуже залежить від ефективності декодеру, щоб він встигав декодувати достатньо інструкції, щоб було що пересортувати.

Це спільна риса і x86, і ARM процесорів, тому що кожна архітектура процесорів має свої властивості і заставляти світ перекомпілювати увесь софт під новий процесор при кожному релізі нереально. Отож і маємо товстезний шар сумісності.

Ось і наблизились ми до суті історіі. x86 мають довільну довжину інструкції, наразі від 1 до 15 байт. І це значить, що розпаралелити декодування дуже важко. Статті, які я читав, рапортують, що максимальна кількість декодерів у процах Інтела та АМД - 4 на кожне ядро проца.

На відміну від них, у ARM інструкції завжди по 4 байта, тобто бери нарізай бінарник як хочеш і пхай у декодери. І в M1 зараз 8 декодерів. І внутрішнє звірятко через те дуже-предуже ефективне.

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

Кеш — це спосіб уникнути штрафів повторення виконання один і тих самих операцій. Найпростіше, що можна собі уявити — це функція memoize, яка допоможе порахувати числа Фібоначчі швидко без того, щоб думати над алгоритмом. :)

У веб-сервісах є багато шарів, де можна закешувати результат. Перше, що приходить до голови — це кешування запитів до БД. Зазвичай че запит у інший процесс (власне, процес БД), або навіть через мережу у іншого сервера. Тож ми берему якусь кльову бібліотеку (або пишемо самі), якій кажемо: кешуй виклик оцієї функції в залежності від цих аргументів. І параметри до нашого запиту починають параметризувати і кеш. Це буває дуже ефективне місце, навіть якщо кешуємо результати ми у memcached, до якого теж ходимо по мережі. Особливо це ефективно, коли запит складний, а варіативність параметрів низька. У найбільш яскравих випадках взагалі є сенс підраховувати результати заздалегідь і класти їх в базу, отримуючи, так би мовити, нескінченне кешування.

Наступний шар — це рендерінг шаблонів. Йдуть роки, а генерація строк залишається однією з найбільш ємних частин веба. Навіть якщо цей шаблон — це JSON, і (на відміну від більшості ліб шаблонів) генерація написана на C, це займає доволі багато ресурсів. Тож ми можемо закешувати його. Тут треба дуже уважно слідкувати за варіативністю параметрів: якщо у результати попадає ім'я користувача, ми ризикуємо генерувати кеш для кожного користувача окремо і тоді ефективність такого кешування впаде до плінтуса. При цьому при розробці (та тестуванні) все буде виглядати нормально, тому що користувач-то один буде. Це те саме місце, де можна відчути, що кеш — одна з наскладніших проблем у програмуванні.

І з важливого є ще один шар, власне HTTP. У протокол HTTP вбудований механізм кешування, який імплементовано і в браузерах, і в різних балансувальниках нагрузки, як от в nginx чи у Cloudflare. Він нам дуже цікавий, тому що дозволяє навіть з доволі повільним бекендом (на Django чи то на Rails) мати сайт, який відносно нормально витримує навантаження. У будь-якій HTTP відповіді можна додати хедер Cache-Control: max-age=3600 (припустимо), і браузер, який отримав цю відповідь, ще годину не буде повторювати цей запит. Ще цікавіше: якщо перед нашим сервером сидить якийсь проксі, то він теж закешує ту відповідь і жоден запит з будь-яких браузерів з тим самим урлом вже не прилетить до бекенду.

Ми цим кешуванням дуже широко користуємося у Касті. Як API, так і усі публічні сторінки рендеряться так, наче їх дивиться анонім, а потім фронтенд біжить і довантажує кастомні елементи (насправді, у більшості випадків — хедер, де є ім'я користувача).

Правильно побудоване кешування — дуже ефективна штука, тому що найшвидший код — це той, який не потрібно виконувати. #cache #performance

В мене у Києві є улюблений ресторан. Насправді, назвати це місце рестораном важко… але вони готують їжу, і в них можна сісти у залі поїсти (хоча останній рік тільки на виніс), і це не фаст-фуд, тож мабуть таки ресторан?

Це Пекін на вулиці Васильківській, навпротив корпусів універститету Шевченка. Так, у Києві є ще інші ресторани з такою назвою, і є багато інших китайських ресторанів та доставок, але всі вони — не те.

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

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

Раніше там всередені взагалі був сюр і гнучкі алюмінієві виделки. Гнучки не у сенсі «гнучка компанія», а у сенсі «вирівняй перед тим, як їсти», як ото у совкових столовках. Але вони оновили інтер‘єр, поміняли посуд і тепер просто так собі. :)

Це не висока кухня, це смачна кухня. Обожнюю і свиню по-пекінськи, і курку по-сичуанськи, і яловичину з китайськими приправами, і смажені пельмені з бараниною, і купу купу всього іншого. Взагалі, якщо в темі і я не згадав ваше улюблене, пишіть в коментарях для тих, хто там не був, бо Пекін сяє наче Бетельгейзе у світі китайських ресторанів Києва. :)

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

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

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

Тож в доволі короткий час я записав все що треба. Ура, 80% праці зроблено! Лишилося тільки змонтувати і почистити звук, тобто ще 80% роботи.

Думаю чи не звернутися мені до професіоналів… бо я ж ще не вмію файнал кати всі та інше. :/ Але непокоїть що там треба фокус то на код наводити, то ще кудись, чи воно реально з кимось зконтактувати, щоб і нормально вийшло, і всі штани не зняли… Але загалом я прям дуже радий, що нарешті зробив та записав це. :)

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

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

Лежу без сну вже третю годину і думаю, чи записатися у екстремісти, чи у ескапісти?..

Розміри

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

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

Тож ідея така: ми назначаємо якісь (українські, насправді) сітки "стандартними" на категорії товарів. Таки сіток вийшло з півтора десятка — для одягу, взуття, білизни тощо. І потім постачальникам кажемо підбирати до свого товару той розмір, який збігається по вимірах з його товарами.

І тепер ми маємо два варіанти — традиційний, коли на товарі висить якась його розмірна сітка (скажімо, міжнародна S/M/L), чи українська, а ми кажемо "на товарі буде написано S" (не завжди так, може бути і 12, і 43, і ще якась хрінь, воно різноманітне).

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

Іншими словами це називається так: ми намагалися різноманітність реального світу запхати у видумані рамки розмірів, ще й уніфікувати їх для зручності покупців. В офлайнових магазинах це вирішується тим, що є знавець розмірів (консультант), який тебе розпитує і розглядає, і потім щось радить. Але ж що робити в онлайні? Чи є в нас щось таке, що відображає реальний світ?

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

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

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

Як в нас на сайті був React всюди, то в якийсь момент ми навіть перестали читати Sentry. Ну типу звідти йшли нотіфікації, і раз на якийсь час там бували реальні помилки, які можна виправити, але після чистки від дурні на самому початку там було звалище незрозумілих помилок від старих браузерів, з відсутніми стектрейсами. Їх взагалі не дуже реально відшукати у тому бандлі, що являє собою реакт-апп, а ще вони трішечки різні і кожен на невеличку кількість народу спрацьовує - той на хром 39, той на оперу 36, той на ще якусь хрінь.

А помилок від IE11 та схожих браузерів там взагалі нема. Ми колись, році ще у 16-17, виявили, що MS Edge не хоче завантажувати наш сайт. Згодом знайшли в офісі комп на 32 Гб ОЗУ та десктопним процом, і змогли завантажити, і воно навіть якось рухалося, але ж це не життя. :) То я зарепортив як баг у Edge, і через три місяці вони сказали, що таки так, це баг у Еджі, а ще через рік вийшов реліз з фіксом, а ще через рік (чи щось таке) вони замінили в Еджі нутрощі на Хроміум. Тотальна перемога. 🤣

Але тепер в нас в Сентрі є окремий проект на баги джаваскрипта, які летять з Твінспаркової версії. Там є трішечки цікавого, що складно розібрати, а ще є трішки багів з IndexedDB, які незрозуміло як вилікувати... Але більшість багів нескладні, зрозумілі, і зазвичай "якесь старе падло щось не вміє".

І їх можна вилікувати! Типу вчора помітив, що на старих браузерах не працює наша аналітика, бо ми там заюзали Object.assign. 3 хвилини, і ще 600 користувачів тепер нормально трекаються. А зара сиджу, дивлюся і не можу вирішити, чи робити щось з тим, що IE11 не вміє Promise, чи забити на них усіх, їх всього 800 користувачів за три місяці...

Розповім, мабуть, про те, як мій тєлік Самсунг відмовлявся ютуб показувати. Місяці зо два чи три тому почалося, типу вмикаєш його — а в аппці ютубу відео навіть не починає програватися. Для контексту — йому десь під 4 роки, тож досить новий, але у тогорічну програму боротьби з сірими тєліками він не попав. Сірий, так, модель щось на кшталт UE55MU7002 (насправді рівно так, я вже запам'ятав це зовсім).

Якщо висмикнути з розетки, почекати трішки, а потім увімкнути - все працює. Іноді кілька днів працює, а іноді тіки цю сессію, треба знов ребутати. А якщо під час того, як він не працює, зайти подивитися на стан мережі, то він каже "не бачу інтернету". Локалку бачить — він в мене навіть на дроті сидить, а інтернет — ні. Ну, думаю, падло ти таке, Гнусмас, напав на мене! 👹

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

Тож так ми і жили з ребутами, та щось вони все рідше допомагали, аж доки тижні два тому наш тєлік не перетворився у гарбуз, який може тіки дісплеєм для компа служити. Що не дуже зручно для ютубу, насправді… 📺

І ось на минулих вихідних я прокинувся сповненим рішучості цього демона перемогти. Колупав все що міг, знайшов навіть що є прошивка минулорічна, яка автоматом не оновила, відшукав флешку (теж щє квест) і оновив, і ніфіга. Аж раптом дружина зайшла у налаштування мережі з іншого екрану, а воно і каже - з DNS could not resolve. Ооо, думаю, бач як заговорив, в інших екранах (нашо їх так багато?) ти тіки таємничу помилку 92 мені звітував! 🤖

*DISCLAIMER*: далі три абзаци технічного кошмару, просто перестрибни їх :)

А ще два дні тому помітив що я його пінганути не могу по тому айпі шо в роутері я бачу. Тож, думаю, піду подивлюся, що в мене там в роутері взагалі в налаштуваннях є... Відкрив, поклацав все у Advanced, ну якось наче ніяких фаєрволлів, нічого... Думаю, добре, ну в мене новий ноут, то хоч прив'яжу його до стабільного айпішнику, чом би й ні. Прив'язав... і тут мене наче молнією ⚡️ вдарило! Дивлюся, а там прив'язаний тєлік, до айпішнику 10.0.0.105, який він зараз має, але ж це я робив ще коли він на вайфаї сидів, а зараз-то він на проводі тож мак-адрес там зовсім інший!

Видалив ту прив'язку і все запрацювало наче на дворі ще січень! 😁

І тепер в мене купа питань: якого біса роутер давав зайнятий айпішник йому? Чому, скажімо, не моєму телефону? Чому я його прибив до 105, якщо DHCP починає роздавати з 100, чому не просто до 5? Чому, хоча я й прибив ноуту айпішник 10.0.0.2, він все одно брав собі 102 і все? І головне, чому тєлік той почав глючити у лютому, а не коли я в нього позаминулого року виту пару встромив? 🤡

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

А ще, зовсім випадково, через історію з телевізором я дізнався, що RJ-45 — це помилкова назва, і це інший, дуже схожий роз'єм, з телефонних мереж, а комп'ютерний правильно називається 8P8C. Weird, ain't it?

Ось, подивіться.

У далекому 2009 в мене був цілий місяць (грудень) між роботами, і я його тоді провів дуже продуктивно — наприклад, написав клієнтську бібліотеку до Редіса (на пайтоні), основну фічу якої автор redis-py потім перетягнув до себе, бо там була нереальна економія на кількості коду. А ще круто роздуплився з метапрограмуванням у пайтоні, що дуже допомогло написати ядро системи на наступній роботі, а потім нереально допомогло вичистити код від метапрограмування на пайтоні на той що була наступна за наступною. 😁

А ще написав малесенький пастбін — paste.in.ua, тому що мій звичайний через раз бував у даунтаймі, а юзав я його багато. І вже давно всі результати того місяця залишили після себе тільки досвід, а PIU досі живий, і я минулого року його навіть на Кложу та ГраальВМ переписав.

І у процесі переписування думав перевести сховище на SQLite, щоб простіше було то все менеджити, але виявилося, що драйвер склайту для джави не компілюється у статичний бінарь під лінуксом (на відміну від мака та вінди), тож дзуськи. На жаль, я не спеціаліст у війнах з gcc та C++, і проблема досі не вирішена, тож я залишив той формат зберігання, що там є, у файлах. А там... неортодоксальна серіалізація. :)

Зед Шо мені нашепотів заюзати для енкодінгу tnetstrings, формат, прикольний своєю простотою. 😂 Але коли я переписував все на кложу, я знайшов лібу, яку написав американець (це важливо). І через не дуже приємний код я ту лібу переписав трішечки симпатичніше, але! не дуже замислюючись.

Чому американець і моя тупня важливі? Тому що стандарт каже: довжина у байтах. А джава оперує строками, а не байтами, і в мене вийшла ліба, яка зберігає (і читає!) довжину у символах UTF-8. 😵 Вчора вночі прилетіла нотіфікашка "здох твій піу", і виявилося, що хтось там питав один і той самий урл з помилкою доволі часто, і Грааль закрешився, бо не вистачило пам'яті.

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

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

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

А потім ті дані, які збирає Хром з усіх користувачів і про які так давно точиться дискусія у privacy-minded колах інтернету, вони нарешті застосували на користь широкому загалу. Себто для нас з вами. І тепер метріки Гугла для сайтів — це те, що зарепортили браузери користувачів. У Google PageSpeed Insights можна подивитися на результати кожної сторінки, а у treo.sh добрі люди навіть зробили інтерфейс, де можна подивитися результати загалом по домену. Що, до речі, дуже цікаво!

І тож, не дивлячісь на неідеальний Lighthouse, можна оріентуватися на реальних користувачів та їхні проблеми. Лайтхауз — це опенсорсна тулза, яку в Гуглі написали як бекенд для PageSpeed'у на заміну того YSlow-подібного жаху, що був раніше — все ж таки синтетичний тест і навіть на кількох послідовних запусках дає різні результати. А тисячі користувачів дають реальну картинку.

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

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

Авжеж, ггг. Мало того, що всі ці приближення та посування відео — нереальний гемор, дуже багато праці руками, так ще й прем'єр виявився глючним. Він 4к відео з мого десктопу при ресайзі на різких змінах перетворював на покоцані фільми з 90-х, коли обличчя ГГ кудись у квадратиках упливає. Експортиш кудись — воно втрачає всі ці приближення мої... Кароч задовбався! Зробив потом з джерела MJPEG і ото так воно якось проїхало. Хоч не торкайся тої скотини прем'єра.

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

Але вже не можу далі, хоч воно і не ідеальне. Можна вже йти дивитися! :)

Якщо у перший раз я на відео потратив, думаю, годин 15-20: кілька разів записував все наново, розбирався з прем'єром та взагалі з підходами до монтажу, і взагалі мучився, то головний доробок на цей раз забрав 2.5 години на те, щоб все записати і нарізати. Частково це тому, що я все робив у епловому Final Cut Pro, а не в адобівському Premiere Pro. І воно якось так зайшло, вся ця ідея с "магнітною" стрічкою і взагалі інтерфейс... Думаю, що третю спробу треба пройти у Davinci Resolve і в кінці вирішити, з чим жити. А потім ще стільки же на всілякі дрібнички, як без цього... :)

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

А це означає що? Точно, рассінхронізацію відео та звуку! 6 кадрів, щоб ви розуміли. Порахував я ці кадри, рухаю на 6 кадрів звук, а різниці немає. У інтернеті замість інформації хлам всякий, який я наче і сам знаю, але нічого не виходить. Перемотуємо на 5 днів вперед, ще один підхід, і поки я розповідаю брату про свої негаразди, до мене доходить, що я не звернув уваги на формат часу, і там не кадри, а долі секунди! Себто у головному індикаторі 00:02:47:16, де 16 — це кадри, а тут 00:00.87, вочевидь це не 97 кадрів! Ок, 1000/30*6 = 200, рухаємо на 00:00.20, ніфіга.

Записую клацання пальцями, значить, поставив головку де на відео вони змикаються, тягну звук... 00:06.00! Капець, то соті кадра! Як я мав здогадатися взагалі?! Ну хоч би якусь індикацію, не знаю, ото вже боги інтерфейсу. :/ Не те щоб в прем'єрі все було зрозуміло, але ну це було якось дуже боляче. :)

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

Коли дивлюся демки no-code/low-code інструментів, мене не покидає відчуття незручності цього підходу. Тільки що дивився internal.io (те відео, що в них на головній) — там пані наклацує мишкою інтерфейс адмінки. Воно з однієї сторони прикольно, з іншої їм прийдеться поверх того всього вигадувати систему версіонування, інтерфейс до неї, а всім звикати і колотися, як отим їжакам. Ну

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

Плюс адмінки все одно роблять програмісти. Ось 1С багато зробив, щоб це все легко можна було зконструювати, у нескладних випадках просто мишкою. І що, багато бухгалтерів тепер не просять когось зробити їм звіт, а роблять самі? Індустрія вокруг запитів бухгалтерії склалася ціла.

Підсумовуючи: мені все ж здається, що захід з іншого боку, типу low-code, але у коді, був би ефективніший. А возіння мишкою то прикольно, але ще й лейаут на ходу видумувати — додатковий гемор. Хтось може вже використовував таке? Internal.io, retool, може ще щось такого типу?

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

А потім я виріс — і все одно нічого не зрозумів. Англійське право — це якийсь древній трухлявий підхід чи то вікінгів, чи то германців-дикунів… Не те що модерновий римський підхід, що його скрізь у Європі запровадив Наполеон!

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

Аж тут читав трішки історії — перший процес з теми сегрегації у США, в якому вирок прийняли на користь відміни власне сегрегації, відбувся у кінці 19 сторіччя, а остаточний процес та вирок — аж у 50-х. Тому що неможливо взяти і прийняти вирок, який прямо протилежний усім попереднім прецедентам — і знадобилися десятиріччя праці адвокатів та суддів, щоб розвернути ситуацію.

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

Але ж гроші люблять що? Тишу вони люблять, та спокій! І англійське право цінять за його стабільність. Ось що головне! Ситуація навіть якщо і буде змінюватися, вона буде це робити довго, і ти встигнеш приготуватися.