Доволі цікаво, як Епл використала один і той самий процесор у зовсім різних сегментах. І мак міні за 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-х. Тому що неможливо взяти і прийняти вирок, який прямо протилежний усім попереднім прецедентам — і знадобилися десятиріччя праці адвокатів та суддів, щоб розвернути ситуацію.

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

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

Подивився тут інтерв'ю з Миколою Аліменковим, і, після купи дуже розумних думок наприкінці (45:12) він каже: "яка різниця, на якій мові це робити". Вочевидь, в мене на це питання прямо протилежна точка зору (інакше б я десь біля джави чи якогось пхп тусувався, правда?): інструменти дуже сильно впливають на результат.

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

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

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

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

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

Тож viva la Clojure та єдиному пророку її: Річу Хікі! 🤣

​Нам з братом пощастило у дитинстві: на одному з дисків зі збірками ігор була TTD — Transport Tycoon Deluxe. Сенс гри у тому, щоб організувати транспортування товарів з місць виробництва до місць споживання. Бувають короткі маршрути, скажімо, вуголь до ТЕС, бувають довші: залізна руда — сталь — товари, які потім треба возити в міста, щоб вони росли. Перевозити їх можна вантажівками, кораблями, літаками, і, найкраще — потягами. Прокладаєш маршрут, розставляєш семафори, і пішло-поїхало. :) Гроші заробляються на транспортування, до самого товару ти якби відношення не маєш.

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

І ТТД наче залишився там, у дитинстві, та іноді у спогадах, але вже на першому курсі у ньюсах КПІ я натрапив на обговорення TTDPatch. Сам TTD був, вочевидь, програмою з закритим джерельним кодом, ще й на асемблері — бо Кріс Сойєр таки олдскульний дядько, і навіть Locomotion 2004'го року написаний на асемблері. Але знайшовся чувак за ім'ям Йозеф Дрекслер, який з 96 року (враховуйте, що перший реліз оригінального Transport Tycoon відбувся влітку 94) працював над in-memory покращеннями гри. Цей патч виправляв купу неприємних особливостей гри і додавав багато нових можливостей.

А ще тепер інтернет був значно більший, ніж у 96-97 році, і можна було почитати туторіали, як інші люди грають. Це був ренесанс ТТД для мене і відкриття року для купи народу в общагах, хєхєхє. Ми нормально навчилися грати і заробляти гроші, і взагалі виявилося, що гра фанова не тільки для 11-річних дітей.

А у 2004-му Людвіг Стрігеус (який згодом стане доволі відомим, бо він є автором μTorrent) стартував проект OpenTTD. Все ж таки TTDPatch не міг зробити всього, що хотілося спільноті, тож реімплементація гри на C з відкритим джерельним кодом це було то шо треба. Воно вистрілило і розробка йде до сих пір: їх сайт каже, що останній реліз, 1.11.2, вийшов 3 травня — незабаром вже буде 20 років проекту!

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

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

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

Воно лежало без діла доволі довго, але тиждень тому якось ми на неї напали і активно розгадували (у сенсі не тіки Степан це робив)… аж тут козявка Фаня три дні тому кудись заховала книжечку із завданням.

І тут виявилося, що ніхто з нас не спроможний просто скласти ці довбані фігурки. Дуже неприємне відчуття, чесно кажучи, наче знов на дворі 94 рік і мені потрібен iddqd щоб пройти перший рівень…

Я ж півроку тому купив Соньку a5100 і продав свій Фуджик X-T1, тому що він не вмів видати по HDMI живу картинку — тільки те, що вже записано на картку пам'яті. Ну і ще тому що я його кілька років не чіпав. :) І Сонька за свої гроші виявилася дуже розумною покупкою, майже за гроші Logitech Brio, але з набагато кращою якістю.

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

Походив, помучився, чи воно мені взагалі треба — попередній же ж лежав без діла реально, але ну скіки ото можна страждати, і купив Fuji X-S10. До речі, виявилося, що представництво Fujifilm дає фотіки на тест-драйв на кілька днів. Я так взяв X-E4 з 23/1.4 — ніколи в житті не користувався таким світлим склом — і зрозумів, що об'єктив то воно, а форма фотіку мені потрібна від зеркалки, а не від далекоміра.

Тож X-S10, плюс в мене ще залишилися об'єктиви від X-T1, плюс я купив Viltrox 23/1.4 (тому що він 400$ замість 1000$ за фуджиковське скло, а з якістю все супер). Сказати, що то кайф — нічого не сказати. Просто тащусь від камери, та й від скла теж. Результуючі фотки просто фантастичні, керування кайф — що завгодно з кнопок та крутилок можна переназначити на інші функції, ну й взагалі і форма, і керування супер.

Живлення по USB-C, плюс швидкозйомна площадка вирішують траблу з тим, щоб його зняти або поставити секунд за 10, так що він не намертво стоїть біля компа.

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

А ще макро... ​

Пару тижнів тому у мене разів 5 за день поламався інтернет. І так цікаво воно відбувалося, що ребут роутера не допомагав. А ось відключення шнурку від роутеру і втикання назад допомагало: провайдер каже "порт завис". У мене було таке один раз минулого року, один раз 1 квітня (пам'ятаю, бо це прям посеред стріму відбулося), і ось 5 разів за той день.

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

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

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