На тижні прийшлося написати невеличкий парсер, для розбору пошукового запиту (ну, знаєте, “шось OR (шось AND шось)”, трошки більш заморочено). І, мушу визнати, це було боляче. :) У мене в житті ніколи не було періоду, коли б я займався парсерами довго, і тому кожен раз я розбираюся, пишу, роблю паузу в кілька років — і приходиться розбиратися мало не з нульовими знаннями, забувається все дуже сильно.

Це дуже бісить! Написання простого рекурсивного спуску (recursive descent) — дуже проста річ, яка повинна бути в арсеналі кожного програміста. Бо відсутність розуміння, що ти це можеш зробити сам — приводить до того, що в потрібний момент ти не побачиш короткого шляху.

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

Але ж його більше ніхто і не прочитає, про парсинг і так тищі раз написано, то може зробити стрім? З написанням простого парсеру на джаваскрипті, без пріоритетів операторів (EDIT: капець, я не знав, чи забув, що в AND та OR є пріоритети - але робити їх не хочу все одно), щось невеличке. Цікаво б таке було взагалі? Десь сьогодні о 17 чи 18? Я думаю, що навіть з поясненнями це буде година-півтори.

Я сприйняв 50 вогників на попередньому пості як сигнал, що таки цікаво, тому давайте, сьогодні на 18:00 за Києвом стрім про написання рекурсивного спуску на JavaScript’і, будемо парсити якусь нескладну мову. Я поки не вирішив яку, то можна в коментарях пропонувати, але вагаюся між шелом (cmd arg1 arg2; cmd “arg 3”), спрощеною версією ікселевських формул (=if(true, 1+2, “ha ha”)), чи там синтаксису для пошуку (типу what and why or when). Хз, пропонуйте в коментарях.

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

Не забудьте розшарити другу, бо як він інакше дізнається про стрім? :)

через дивний глюк ютуба і обс стрім буде тут: https://www.youtube.com/watch?v=hRiTbk1_R_k

Я вчора трохи здивувався тої кількості порад “та просто візьми лібу” для рішення абсолютно простої проблеми. Не тільки здивувався, а посеред стріму навіть розізлився на чувака, який скіпнув все обговорення того на початку і прийшов принести свою мудрість. :)

Я порефлексував на це все і прийшов до двох думок.

Перша, конкретно про ситуацію: уявляєте, як я роблю стрім “дивіться як писати сортування”, і всі радять викликати .sort()? Не здається смішним? :)

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

Власне: не вмієш нічого? Авжеж, візьми фреймворк, зроби щось, а потім почни його розбирати на запчастини. Чому форми працюють саме так? Чи можна краще? Як працює HTTP? Та сама історія з ORM: це гарна стартова точка, але якщо ти на тому старті так і залишишся, то це буде трошки сумно. Авжеж, можливо ти пішов розвиватися у іншому напрямку, і ORM для тебе тільки інструмент для досягнення мети — але тут я напевно про кардинально інші напрямки, а не про “я розвиваюся у зарплаті, а не в технологіях”. :)

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

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

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

Широта світогляду розвиває людину, а запиратися у мушлі — моветон. :)

У Реддіта повстання ком’юніті у повний зріст. 🤣 Спочатку багато великих сабредитів позакривалися (перейшли в приватний режим), і spez (Стів Хофман, засновник та наразі CEO) почав розповідати у інтерв’ю, що “модератори тримають у заручниках всю ком’юніті”.

Тож великі саби на кшталт r/pics зробили голосування, і в них тепер нові правила — можна постити тільки фотки Джона Олівера. Шкода, я так і не зрозумів, чому саме його — але r/pics повністю з фотожаб з ним останні дні і це капець, сміюся кожен раз як відкриваю глянути, шо там. 🤣

P.S. Джон Олівер підтримує протест — і в своєму твіттері купу фотожаб напостив. 😁

Бачили анонс телеграма про сторіз? Там після нього ще є відео, авжеж, але мене зацікавила одна конкретна фраза:

> Speaking of channels, they will benefit from more exposure and subscribers: once we launch the ability to repost messages from channels to stories, going viral on Telegram will become a lot easier.

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

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

Менеджмент і лоу-перформери

Спочатку мав розмову, яка підштовхнула до цього посту, а на наступний день слухав третій випуск Hackers Incorporated — і там DHH озвучив ту саму думку, тільки в профіль.

Не витрачайте часу на лоу-перформерів. Набагато ефективніше витрачати час на хай-перформерів. Девід це назвав cuddling management, але це в принципі те саме, що helicopter parenting — не треба сидіти з людьми, як з дітьми. Неможливо навчити людину плавати — можна допомогти, підштовхнути, підказати, виправити, але рухати своїми руками і ногами може тільки вона сама.

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

Цікавий факт, що не зважаючи на твої переживання, що 1 людина це може чверть команди (наприклад), швидкість команди завжди росте, коли ти прощаєшся з low performer’ом. Бо і не відволікає, і наскільки ж приємніше працювати в команді крутих спеціалістів. :)

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

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

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

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

Знаєте, чому Emacs — крутий? Не тому, що йому 30 років, і не тому, що він навіть кавоварками може керувати, і взагалі не тому що оті всі жарти які придумуються. Його головна якість не дуже очевидна, якщо не занурюватися в тему глибоко.

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

Імакс працює зовсім не так! Скажімо, є функція find-file, яка відкриває файл. Хочеш розширити її функціонал? Заміни її своєю! Тобто манкіпатчинг, або, як то кажуть, molding — створи свій імакс для себе, заміни все що хочеш тощо. Більше того, вона ж на ліспі написана, можна піти подивитися сорси, та замінити будь-яку з тих функцій, що використовуються всередині. Endless possibilities.

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

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

Тим не менш, це саме те, що дозволяє Emacs’у бути чим завгодно. Якщо хочте, Emacs — це 1С текстових редакторів. 🤣

P.S. Платформа vs фреймворк vs конструктор. Фреймворк — це коли ти заповнюєш певні місця своєю логікою, конструктор — коли збираєш з модулів, платформа — це коли є працююча програма, від якої ти можеш відштовхнутися. В принципі, можна сказати, що Emacs — це ОС, тільки спеціалізована і трошки вище рівнем абстракції.

Ого, TwinSpark.js в топі на Hacker News! А підіть апвотніть пліз, якщо вам не шкода, нехай ще трошки повисить. 😁

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

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

Знаєте історію, як при презентації дропбокса на HN хтось написав комент “це ж тривіально зробити з FTP + curlftpfs + SVN”? Очевидно, що людині важкувато помітити проблему, коли вона в деталях на ній розуміється.

Це я, literally. Коли мій одногрупник якось показав Дропбокс на 6 курсі, я такий — Сергію, ну і нафіга це? Я ж он фактично те саме маю, осьо диви, лінка — а файл у мене на SliceHost’і лежить (хто знає той знає ггг).

Згадується ще Emacs — а за IDEA платять, мій сетап проксі — а за ngrok платять, і напевно можна багато чого ще вигадати. :)

Це я сам собі пост пишу, напевно: коли щось — тривіальне, але окрім тебе ніхто його не сетапить, то це натяк на потенційні гроші. 😁

Прочитав тут історію про те, як Макс Левчин розважався, коли був СТО PayPal’у. Історія цікава, чувак очевидно був капітальним задротом і в якийсь момент не стримався і зробив крутий солюшен, щоби нерви собі полоскотати. :)

Мене, правда, більше зацікавила не основна сюжетна лінія, де він захоплюється криптографією, і робить круті штуки (хоча й змушує трохи синдром самозванця підняти голову, мене в такому віці більше цікавила Diablo 2 😁), а оточуюче середовище. А конкретно прохідна ремарка про “automated deployment script copied shard files to their destination”. Події, нагадаю, відбуваються більше 20 років тому, а в чуваків сетап краще, ніж часто зустрічається зараз.

Ніяких тобі пхпшних “відредагую прямо на сервері”, очевидно, ха-ха. Напевно Пейпал і в США не був середньою компанією (ну не з таким СТО, ггг), але змусило трошки задуматися, що нажаль в нас не було нічого подібного, коли моя кар’єра починалася. :)

Я вже якось торкався теми заміни 1С’у, а тут мене нещодавно тригернули, і в мене чухається знов за це поговорити. Те відео в двох словах: 1С це платформа для автоматизації бізнесу, яка маскується під систему бухгалтерського обліку. Так само, як SAP маскується під ERP, а Salesforce маскується під CRM. Вони всі заходять з різних сторін, результати виходять трохи різними, але тим не менш їх мета одна: стати хребтом бізнесу, щоби не бути заміненими ніколи.

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

Сховище даних

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

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

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

І, авжеж, API для забирання/додавання даних треба прям повноцінний і адекватний.

Базовий інтерфейс

Загалом, більшість підприємств починають автоматизацію бізнесу з Excel/Google Spreadsheets, тому ця абстракція здається дуже корисною. З іншого боку, здається що інтегроване щось на кшталт Metabase було б екстремально корисним, бо будувати дешборди в Ікселі можливо, але воно трошки занадто громіздке виходить.

То от здається, що якась абстракція, коли на канві можна розташувати графічки, таблички чи там інпути — корисне. В Decipad от щось таке роблять, заодно звертає на себе увагу, що в таблички замість A1/J66 є нормальні назви в колонок.

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

Інтерфейс для користувачів

При тому дати таблиці всім — не звучить як дуже безпечний і зручний механізм. Якщо ти просто продаєш каву, заповнювати табличку здається не дуже адекватним. 😁 Мені дуже подобається, що будує Retool, такий собі no/low-code генератор інтерфейсів. Чесно кажучи, мені не дуже ясно, наскільки далеко можна зайти з no-code і наскільки воно потрібно, заходити далеко — але в ідеалі якісь не дуже складні, але тим не менш функціональні інтерфейси повинні бути доступні для нормального користувача. Нормального у сенсі що Іксельні абстракції цій людині доступні. :-)

P.S. Продовження нижче.

…продовження поста про заміну 1C.

Процеси

Оце цікаве місце. Очевидно, що якісь зміни повинні вміти тригернути інші зміни, або якусь інтеграцію, абощо. Можливо, тут є сенс подумати над інтерфейсом а-ля Yahoo Pipes, або Zapier/n8n/Huginn/шо там ще є на ринку. Тобто готові шматочки, які можна комбінувати. Це те, що робить Corezoid, як я розумію, а ще в мене є знайомі в Нідерландах, які будують Stekz, і я думаю, що таких речей по світу багато.

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

Модулі

Найскладніше. Я, нажаль, не дуже розуміюся на тому, як в 1С (наприклад) інтегруються різні рішення від різних контор (підозрюю що як і всюди, за допомогою програмістів і з купою нервів).

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

Як це обійти — дуже цікаве питання. Можливо, дуже високорівневі абстракції спасуть ситуацію: типу оцей модуль потребує колекції документів в такому форматі, і ти йому в’юшкою і джойнами організуєш і віддаєш (тобто відривання інтерфейсу роботи з данним від власне зберігання даних). Тут в мене настрій коливається від “модулі нічого не повинні знати про зберігання” версус “модулі повинні абстрагувати зберігання, а назовні виставляти інтерфейс, який потім виглядає як таблички”. Оце друге здається складнішим для імплементації, але перспективним з точки зору збереження зворотньої сумісності. І перетинається дуже з API доступа до даних, куди цікавіше було б вміти тикатися в інтерфейси, а не прямо в сирі дані — тоді є шанси апгрейдити зберігання, не ламаючи зовнішні інтеграції.

The End

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

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

‍Чи можна вчорашні події розглядати як символ суттєвості кроків, які Україна зробила для здобуття перемоги? 🤣 Здається, що чим більше тиску буде на полі бою, тим цікавіше будуть розгортатися події на росії. Вони вже почали святкувати 24.08 в себе закриттям офісних центрів, червоної площі тощо. 😁

Тому дуже хочу подякувати всім, хто захищає нашу країну! І вітаю всіх із Днем Незалежності!

Я позавчора спав на невдалій подушці і потянув собі шию і шось там в лопатці (talk about privilege 🤦‍♂️). Спочатку було неприємно просто, а сьогодні о 5 ранку прокинувся, бо вже капець боляче було. І шо, коли ти о 5 прокидаєшся, то вільного часу багато, я вже і рілзи до кінця додивився, і твіттер двічі прочитав, тож чимось занятися треба — і я пішов шукать вправи, як полікувати той біль.

Ютуб повний всіляких “візьмить рушничок і отут тягніть по діагоналі” і схожих речей, які я чесно виконував і нічого не добився. Аж після обіду зайшов дещо корисне переглянути (доповідь про Electric Clojure), а мені ютуб запропонував відос, де на тамбнейлі була лопатка, а не шия.

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

У fwdays тепер є новий подкаст, зветься A&B Show (це архітектура та бекенд), і в першому випуску Єгор (ведучий подкасту власне) вирішив спростити собі вибір людини для інтерв’ю — тобто записав його зі мною. 😁

Він не дуже уважно стежив за моїми виступами (shame on you, Єгор! 🤣), і тому прийшлося розповідати більш грунтовно, ніж я очікував. Тож якщо вам цікаво, велкам подивитися першу частину (друга буде через кілька днів/тижнів/побачимо): https://www.youtube.com/watch?v=Xs6ED_v9TzY

Друга частина підʼїхала: https://www.youtube.com/watch?v=dcsxakISVCw

Там 21 Джава вийшла, якщо ви не бачили, і в ній величезна зміна — віртуальні треди тепер глобально доступні. Це прям фантастична новина, на мій погляд, тому що можна ввід/вивід та різного рода конкаренсі ефективно використовувати без асинхронного сміття типу колбеків етц. Це значить нормальні стектрейси (а не як після Netty), і ефективніше, ніж зі звичайними тредами, планування роботи, бо вони N-to-M — тобто N віртуальних тредів виконуються на M реальних, це значить в нас є і параллелізм, і рівночасність (concurrency).

Це кайф взагалі, і дуже сподіваюся, що ком’юніті і Джави, і Кложі займеться цією двіжухою і набудує різних покращень життя навколо. В принципі це можливість побудувати core.async без всієї магії всередині. Гм. 😁

Рон Преслер, лід розробки віртуальних тредів, дуже давно почав цим займатися, ще років 10 тому зробив quasar/pulsar — це власне імплементація грін-тредів як бібліотеки.

Кароч дуже зацікавлений у юз-кейсах, які ця двіжуха відкриває. 🔥

P.S. Тим часом у коментарях на HN срач за те, що для інтерполяції рядків буде синтаксис "\{var}", а не "${var}", як в інших мовах. Поверхневість колег по цеху мене іноді просто вбиває.

Макс в останньому подкасті скаржиться на якість кода Джинні (спойлер: трабла в занизькому рівні абстракцій місцями, нічого складного), “занадто мало за ним стежив”, і таке інше (послухайте сам подкаст для подробиць, там недовго).

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

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

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

Питання: що робити, коли наняв людину для задач, яких ти сам не вмієш? Умовно кажучи, як я прийшов в Касту — Андрій (CEO Касти) не вмів програмувати, не вмів керувати розробкою, і не знав, як виправити проблеми свої, що робити в такому випадку? Імхо, щотижневі 1-1 із зануренням у проблеми, методи їх рішення, і просто навчати. Навчання потребує від того, хто навчає, більшої усвідомленності дій, і дозволить з однієї сторони виправити напрямок, якщо треба, а з іншої — відкриє слабкі моменти/балаболок/тощо.

Ми з Андрієм такого не робили, йому зі мною просто пощастило. 😁 Але ж не кожен така цукерочка. 🤣