Ну нареееееешті я зробив відео з демкою того, як працює 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 роки все було нормально, а тепер що?... Якщо ще раз пропаде, то наберу їх ще раз — аж тут раптом дзвонить телефон, а звідти: "ви оформлювали заявку на гігабіт, вона ще актуальна?"

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

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

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

Ідея така — ти збираєш до купи відомі тобі:

• факти: id товару такий, постачальник такий, ціна така, властивості такі, користувач з Києва, вибрав оплату картою, вибрав доставку у відділення НП, і т.п.
• правила: доставка на кастапост безкоштовна, якщо ти чоловік з трьома дітьми у Києві і платиш карткою Андорри
• питання: чи доставка безкоштовна? чи може треба хінт для сторінки товару про те, що доставка для оплат карткою безкоштовна?

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

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

Судячи з реакції, вчора був занадто технічний пост, тож давайте обговоримо якісь загальнолюдські цінності. Наприклад, колдбрю! :) Беремо чисту холодну воду і каву у пропорції 1:18 — або якійсь іншій, в інтернеті купа обговорень, скільки треба. Я роблю літр води і 55 грам молотої на аеропрес кави і мені подобається результат. Тож цю суміш у банку і в холодильник, а зранку наступного дня (виходить десь годин 16 в мене) фільтруємо і є трішки менше літру дуже смачної кави, яка ще й холодна і у години нестерпної спеки наче нектар. :)

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

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

Кароч, кайфую з результату і не розумію, чому минулого літа цього не робив.

Є така штука - еластіксьорч. В мене з ним якісь love/hate 💔 відносини. Він вміє дуже прикольні штуки, але і має дві вади.

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

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

Почну з контр-прикладу: в постгресі додали можливість вибирати частину JSON'у з поля. І одразу ти можеш це використовувати у селекті, у where, у сортуванні, у агрегаціях, можеш будь-яку строку привести до JSON'у і так само воно буде працювати всюди. Це ортогональність фіч: розробникам постгресу не прийшлось окремо всюди припилювати це механізм, в них нормальні абстракції. 🎉

Натомість давайте подивимость на Elasticsearch. Скажімо, в нас є така штука, як вішлісти. Ти можеш лайкати товари і ми тобі за це потім скажемо, коли на нього впаде ціна. Але є люди, в яких цих товарів дуже багато (десятки і сотні тисяч товарів налайкали, це капець), тож ми їм хочемо дати можливість ті товари фільтрувати. Складати в кожен товар перелік користувачів, у яких він в вішлісті, трішечки нерозумно — популярні товари таки дуже популярні (в найпопулярнішого - 8,5 тисяч лайків 🤯).

Але ми беремо фільтр terms, який дозволяє сказати "хочу лише оці документи". Якби в нас були сотні товарів в одного користувача, то ми б просто їх параметрами запиту передали. Але в нас тисячі (десятки навіть)! Еластік такий: не бійся, чувак, я все шарю. 👌 Диви на доку нижче, якщо ти замість списку термів передаш спеціальну мапу, то це буде означати "хочу документи, список яких є он в тому документі". Ну типу вішліст твій будемо складати в еластік одним документом і потім на нього посилатися (ну теж не дуже ефективно звучить, але ж кращє ніж на читанні таке селектити з бази).

Наче норм, так? Проблему вирішили? Ось тільки ми ж хочемо їх видати так, щоб найсвіжіші (за часом додавання користувачем) були вгорі. А еластік видає як йому заманеться. Добре б його попрохати відсортувати, як у тому нашому документі з вішлістом. Але ж немає шансів! Тому що фільтр термс те вміє, а сортування не вміє. Той "джойн" — не ортогональна фіча. 💩

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

Сьодні зі Степаном пішли на картінг — на «Жагу Швидкості», авжеж, бо де ще можна нормально проїхатися. :) І раптово виявилося, що вони останні два роки вже не пускають повозити дитину на руках. :( А самому йому ще рано, треба 130 см зросту, щоб дістати до газу (кому треба той тормоз).

Тож довелося мені самому разочок проїхатися, тим більш що я там роки 3 вже не був — і перше коло за 43.3 дуже болісно про це нагадує. :)) Колись за 39 з копійками проїжджав сьогоднішню конфігурацію, а зара найкращий результат — 41.7 при тому, що крім мене на трасі тіки ще один чувак був.

Але кльово, приємна втома в пальцях, хехе. Треба ще буде сходити. ;)

Оце вже мошейнікі пішли грамотні, капець. Вчора виставив інтеловий макбук про на продаж на олхі, сьогодні в Телеграм пише мені якийсь Илья Усачёв, і каже — а можна сьогодні в Києві зустрітися купити? А ви вже його почистили? А скільки циклів перезарядки (це трохи дивно, в оголошенні ж написано)?

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

І тут він дуже хоче по телефону говорити — ну ок, і відбувається в нас така розмова:

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

І повидаляв всі мессаги з телеграмівського чату. Хитре падло.

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

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

Я не можу дати якусь моральну оцінку цьому, треба обсмоктати зі всіх сторон, але не можу не звернути увагу на те, що "конкретні бренди" звучить дуже схоже на "конкретні типи" з ООП, на які постійно котить бочку Річ Гіккі. :)

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

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

Мораль: вчися програмувати на кложі — це дозволяє і рибку з'їсти, і на Снікерс сісти. 🤣

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

Скажімо, в нас потроху головним методом платежу стає переказ з картки на картку - дуже швидкий, дуже дешевий (а часто і взагалі безкоштовний), без метаданих та підтверджень. В мене на районі навіть розкладка з овочами приймає такі перекази. Ще й сама пропонує, до речі! Я навіть бачив на свої очі, як бабуся 70+ з монобанка перекидувала гроші, «бо не треба з дрібнотою возитися». Але! Покажи будь ласка екран, що гроші пішли, бо карта - хазяїна.

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

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

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

Тіки шо зрозумів, що Максим Бахматов не дарма називає Київ столицею кіберпанку — це і є хайтеком на мінімалках, який ми спостерігаємо.

Програмування — це такий дивний процес на перетині інженерії та творчості, типа письменництва. Я не знаю, чому воно так, чи це через те, що це досить молода дисципліна ("всього" 70 років, ха-ха), чи це через надмірну складність і величезну кількість варіантів, але результат такий, що це явно не точна наука.

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

Хтось читає про принцип Don't Repeat Yourself, і починає робити параметрізовані функції на всі два випадки, хоча воно простіше вирішується кастомними трьома строками інлайн. Люди надивляться на переускладнені DRY'єм (пересохлі, ггг) кодові бази і потім пишуть у твітері "ні в якому разі не робіть функцію, поки хоча б три рази вона вам не знадобиться!" Впевнений, потім на цю лапшу інші люди будуть дивитися і писати "не повторюйся падлюко!" Хоча капець, це ж просто — подивись на те, що ти пишеш, і подумай, чи це має сенс бути окремою функцією? Це ж просто спосіб зробити абстрацію.

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

Є ще багато правил, які гуляють інтернетом, які одні люди пхають всюди "робіть тільки так", а інші волають "ні в якому разі так не робіть". Але насправді суть у тому, що власного розуму ніякі поради не замінять. :)

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

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

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

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

Є речі, які стають настільки звичними і настільки частиною щоденного життя, що про них перестаєш замислюватися. Наприклад, Кафка. Мова не про грефневу, авжеж.

Що воно таке? Це наче черга повідомлень, але ці повідомлення там назавжди (ну або скільки скажеш, диски ж не безкоштовні). Абстрактно вся кафка це файли зі строками повідомлень і додатково записи про те, на якому рядку кожний читач зупинився. Ментальна модель екстремально проста і через те дуже ефективна!

Що воно нам дає?

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

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

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

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

• id, topic, message
• consumer name, topic, offset

Цього вистачить, аж поки рахунок не піде на тисячі у секунду.

Мораль така: якщо у вас є всередині хттп апі — то час замислитися. А якщо є rabbitmq чи шось схоже — час апгрейдитися. :)

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

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

Чому? Тому що це зменшує кількість страждань у світі. Апка не перестане працювати. Сервіси не зламаються і їх не треба буде лагодити. Клієнти БД не помітять ваших змін. Краса!

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

Коли таких споживачів штук 3-5, перейменовувати поле не хочеться. І не треба. :)

Можна вчитися у Clojure: береш якийсь код на гітхабі, який 8 років не торкалися, а він працює. Фантастика!

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

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

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

Що треба, щоб стало норм? Дивись чекліст! Він упорядкований, кожен крок наближує до ідеалу.

* Скрипт, який буде генерувати артефакт, який буде запускатися: архів, пакет, уберджар, докер-файл.
* CI, налаштованний так, щоб цей скрипт запускався на кожен тег гіта (ну або взагалі на кожен комміт і далі автоматично все викочувати на стейджинг).
* Сценарій деплоя без даунтайму. Забрав сервер з балансування, перезапустив процес, увів назад. Або запустив нові контейнери, перевів балансування на них, повимикав старі.
* Цей сценарій повинен запускатися з якогось зрозумілого місця, а не з ноута якогось чувака. Скажімо, з кнопки у гітлабі, з команди в слаку, щось таке.
* Ось тут вже змінюємо процес і починаємо релізити частіше. Або прям кожну фічу окремо, або кілька. Ми у середньому робимо 9 релізів на тиждень.
* Трекінг помилок на продакшені з нотіфікашками про нові — ну типу Sentry. Воно вже і так повинно було бути, але все ж нехай буде. :)
* Сценарій ролбеку — релізу якоїсь з попередніх версій. Якщо можна швидше, ніж свіжий деплой, то так і треба робити. Це для зменшення стресу, щоб не так страшно було великі зміни релізити. Тіки помилки почали лізти, пішов, стару версію викотив, і можна спокійно розбиратися.
* Опціонально: якщо ви розробляєте гілками у гіті, навчитися легко викочувати ті гілки на окремі піддомени, щоб тестувати і дивитися до мержу у мастер.

Ну й не забувайте просту істину: мізки треба вмикати все одно. Головне — не пройти чекліст 1-в-1, головне — щоб стало добре. :)