Дивовижний світ веброзробки

Доброго понеділкового ранку, товариство! Поки канал активно набирає нових відписників, приймаю ваші побажання щодо дописів на цей тиждень. Буду відвертим, особиста фантазія дещо підводить останнім часом, зокрема через несумісність погоди і моїх планів сходити повудити карасів. Тому делегую на вас контент-план ) До речі, хтось ще цими вихідними робитиме собі вікенд ментального здоровʼя на Карибах разом з Едвардом Кенвеєм? Там, якшо шо, ремейк AC IV виходить. Тож гарного вам усім понеділка і продуктивного тижня вам і вашим Клодам ;)

#партнерський_допис Товариство, тут SKELAR проводить завтра конференцію Code2Lead, головними темами якої є поточні події в tech-світі та яким буде код завтра. Вони зібрали інженерів з найсильнішою експертизою у BigTech і стартапах, аби вони поділилися з вами свом досвідом та знаннями. Формат дуже цікавий — такий собі телеміст між Києвом та Варшавою. Відвідати подію можна буде як офлайн в одному з цих міст, так і долучитися віддалено. Участь безкоштовна, але реєстрація — обовʼязкова. Тож, якщо ви пишете код, будуєте архітектуру, деплоїте в прод і хочете отримати практичні знання, що одразу після події можна забрати у власні проєкти — ця подія для вас. Детальніше про спікерів та саму подію за посиланням: https://bit.ly/3QTe3uQ До речі, серед спікерів фахівці з Netflix, Google, Superhuman, Mono, Perply та інших великих продуктів. Тож не проґавте нагоди та долучіться завтра до конференції Code2Lead від SKELAR!

#про_інтернет Одного погожого ранку Джон Сміт вирушив у мандрівку усього свого життя — він почав своє паломництво до Єрусалиму. Узявши до рук патерицю та перекинувши через плече дорожню сумку, він запитавсь в алдермена: "Як мені дістатися Єрусалиму?". На що отримав відповідь: "Спочатку дійди до Некствілю та запитайся там". Джон докрокував до містечка, де його спрямували до Сімплтонського абатства, а там — до міста Беквотер. Далі його шлях пролягав манівцями й королівськими трактами, дорогою він відвідав безліч міст та містечок, побував у найбільших соборах Європи та бачив незліченні дива, аж поки, за пів року мандрівки, дістався місця свого призначення. І на кожній зупинці він робив завжди одне й те саме — питав дорогу до Єрусалиму, а натомість отримував керунок до наступного місця, де можна було б спитати дорогу. Минуло сім століть, а ми з вами мандруємо світом в той же спосіб. Ну, не особисто. Коли сидимо в інтернеті. І не ми самі, а маленькі жваві пакети, якими обмінюється наш пристрій, поки ми гигикаємо над черговим тіктоком, сидячи у вбиральні. Дійсно, подорож одного пакета надзвичайно схожа із подорожжю Джона Сміта, хіба займає тепер незрівнянно менше часу. Коли наш пристрій хоче надіслати кудись пакуночок даних, він не знає усього шляху, натомість усе, що йому відомо — це пункт призначення та найближче місце, де можна спитати дорогу. У випадку вашої локальної мережі — у вашого домашнього роутера, який недарма має таку назву. Коли пакет приходить до нього, то отримує вказівку мандрувати далі, до роутера вашого інтернет-провайдера, який направляє мандрівника далі. І так відбувається доти, поки він не досягне мети. Протягом цієї подорожі пакет може відвідати багато різних роутерів, і жоден з них не буде знати повного шляху. Лише приблизний напрямок. Чому? Все просто — Інтернет занадто великий. Ваш пристрій просто не може знати повний шлях до кожного сервера на планеті. Та навіть якби й знав, цей шлях може зненацька змінитися наступної миті через низку причин, як-от перевантаження ліній, аварії на вузлах, зміни в політиках провайдерів, недоступність окремих мереж або маршрутів та інші негаразди. Ну а ще різними мережами володіють різні організації, що можуть мати власні правила маршрутизації, і маршрут для нього може змінитися, бо наступні роутери почнуть спрямовувати трафік інакше. Тому набагато ефективніше визначати подальший напрямок руху в кожній контрольній точці замість спроби дотримуватись одного-єдиного шляху. І надійніше. Якщо один шлях перестає працювати, то можна завжди дуже швидко визначити інший. Суттєва відмінність, правда, полягає в тому, що якщо ваш пакет загубився в дорозі, то можна надіслати дані ще раз. Іноді новий пакет піде тим самим шляхом, іноді — іншим, якщо маршрути встигли змінитися. А Джон Сміт, вскочивши в халепу дорогою до Єрусалиму, так і лишився б назавжди безіменною жертвою розбійників десь в глухому закутку Богемії. Підхід з пунктом призначення дозволяє роутерам пересилати пакети доволі швидко. Якби кожен роутер дбайливо вираховував детальний шлях для кожного окремого пакета, обмін даними займав би вічність. Роутер не вгадує напрямок приблизно, а шукає найкращий збіг у таблиці маршрутизації, після чого направляє пакет до наступної станції. Не усі ефективні принципи мусять бути виключно новими. Іноді вони існують століттями і доводять свою ефективність у несподіваний спосіб. Чи гадав Джон Сміт колись, що те, як він мандрує світом, так добре пояснюватиме те, як цей самий світ майже миттєво обмінюється знаннями, інформацією, котиками, пропагандою і світлинами голих сідниць? Навряд чи. Хоча ідею з котиками він би точно оцінив. @babichdev Що почитати: • Common Internet Network Interconnection and Charging Practices • How to properly interpret a traceroute or MTR • Internet History of 1960s

#нове_відео на каналі! Цього разу з Марком, Ярославом і Анною з YouScan говорив про джунів — точніше, про те, чи справді їх ніхто не хоче брати, чи усе ж не так все страшно, і є команди, які навпаки надають їм перевагу. Вийшла розмова про ріст усередині продукту, про синьйорів з ринку, про співбесіди без Event Loop та про те, чому “джун” — це не вирок, а радше стан, з якого треба вчасно вирости. Приємного перегляду! Комент, вподобайка й поширення, як завжди. Дякую ;) https://youtu.be/UtSfAFwNl5k

#нов

Товариство, запрошую вас на мітап у Львові! 25 червня спільнота для айтівців "ЛАМПА" разом з Ruby Labs проведе мітап про те, як змінюється роль інженера в епоху AI. Два спікери: 🎙 Костянтин Гломозда — CTO & Co-Founder, Dym Solutions — про context engineering: як дати AI правильний контекст, щоб він перестав здогадуватись і почав реально допомагати вашій команді. 🎙 Я — про те, чи забирає AI роботу програмістів, чи це просто чергова трансформація професії, де розуміння задачі і відповідальність за результат досі залишаються за людиною. Готуйте найгостріші питання — за найкращі розіграють браслети WHOOP і інші подарунки. Після виступів — нетворкінг у приємній компанії, де буде чим підкріпитись і що випити. Локація в центрі, буде анонсовано додатково. 📅 25 червня, 18:00, Львів 🎟 Участь за донат від 300 грн у фонд KOLO Кількість місць обмежена. Реєстрація обовʼязкова: https://luma.com/rlabs-tmlj

Бравзер прощає дуже багато помилок вашому HTML-документу. Зумовлено це, в першу чергу, принципом зворотної сумісності — веб повинен працювати, навіть якщо ваш документ — дрімуче легасі. І для цього бравзер змушений "додумувати" елементи, щоб побудувати валідне DOM-дерево з того, що ви йому прислали. Правил для такої поблажливості існує дуже багато, тож я не буду намагатися розказати про всі, а лишень огляну основні принципі такої "незламності". Ви можете написати в .html файлі просто:

Hello, world!

і бравзер перетворить це на:

#el(html)
  #el(head)
  #el(body)
    #text("Hello, world!")

Бо DOM-дерево мусить мати кореневий елемент, мусить мати head і body. І йому простіше їх самому вставити, ніж драматично падати під час парсингу. Важливий момент — бравзер при цьому нічого не робить саме з вашим .html. Він бере його за основу для побудови DOM, з якого вже в результаті утворюється відображення документу у вікні переглядача. Так от. У бравзера є багато правил, за якими він обробляє ваш html, і суттєва їх кількість забезпечує певні "неявні" перетворення. Наприклад, необовʼязкові закриваючі теги. В певних випадках ви можете не писати їх через те, як певні елементи взаємодіють між собою. Візьмемо приклад:

<p>Hello
<p>World

Бравзер явно перетворить це на два параграфи:

#el(p)
  #text("Hello")
#el(p)
  #text("World")

Чому? Бо параграф не може містити блочні елементи всередині себе, тому, зустрічаючи відкриваючий тег для блочного елементу після відкриваючого p, він робить висновок, що попередній елемент закінчився, і його пора закрить. До речі, він застосує таке виправлення, коли вам заманеться покласти div всередину p:

<p>
<div></div>
</p>

Це перетвориться на:

#el(p)
#el(div)
#el(p)

Хід "думок" приблизно такий: "так, ось параграф, шо там далі? О, div, значить p треба закрить. Так, div закінчився, шо там далі? Закриваючий p? А шо він закриває? Непорядок! У мене попередньо все закрите, тому тут буде просто параграф. Пустий." До речі, просто текст бравзер не перетворює автоматично на параграф, а створює текстовий вузол, який цілком собі є повноправним учасником DOM. І так, бравзер не вгадує, що ви там мали на увазі. У нього є дуже чіткі правила і механізми "відновлення", за якими він будує DOM так, щоб мати можливість відобразити бодай щось. Якщо розмітка неповна, суперечлива або просто написана не так, як очікує парсер, бравзер не зупиняється. Він намагається зібрати з цього валідну внутрішню структуру документа. Десь він неявно створює бракуючі елементи, десь закриває відкриті раніше, десь переносить вузли в інше місце, десь ігнорує те, що не може нормально вбудувати в дерево. Тому памʼятайте, якщо щось є в html, але чогось не видно в DOM, або воно не на тому місці, то з вірогідністю, що наближається до 100%, це діло ваших непосидючих рук, а не баг бравзера. В цьому немає нічого містичного чи непередбачуваного, усі аномалії в DOM зʼявляються чітко згідно внутрішніх правил. До речі, так було не завжди, і свого часу була спроба запровадити стандарт XHTML, який передбачав дуже строгий синтаксис, і бравзер дуже драматично падав від помилок парсингу. Але це нікому не сподобалося чомусь, і стандарт не прижився. Натомість ми маємо HTML5, що і друзів розуміє, і ворогів уміє прощати. Ну себто ваш кучерявий і неправильний HTML. Якщо коротко: бравзер має величезну кількість правил, трюків, виключень і алгоритмів, щоб змусити ваш HTML-документ відобразитися у вікні переглядача бодай якось замість звалитися з помилкою. Бо сторінка з 1991 року має відображатися і в 2026 році попри все. Ось такий веб дбайливий щодо свого спадку. @babichdev

Коли захтілось ввечері чучуть покодить: 2020 — pet-project 2026 — ✨SaaS✨

#css_in_action Користувацькі CSS-функції уже майже за рогом, тож прийшов час поглянути на них дещо ближче. Сучасний CSS дозволяє вирішувати усе складніші задачі, зокрема через певну реактивність, закладену у CSS змінних, себто CSS custom properties, та широкий спектр нативних CSS-функцій на кшталт clamp(), color-mix() та інших. І тепер ми можемо створювати доволі хитромудрі вирази на кшталт:

clamp(var(--min), 2vw + 1rem, var(--max));

Проте досі перевикористання таких виразів лишається болючою скалкою в дупі. Ми вимушені писати таку логіку наново в усіх місцях, де вона нам потрібна, що, погодьтеся, дещо незручно. Однак надія є, і вже досить давно в роботі знаходиться специфікація CSS Functions and Mixins Module Level 1, хоча й у статусі Working Draft. Зокрема, цей документ вводить поняття CSS custom functions, які покликані саме для того, аби дати можливість створювати власні функції та перевикористовувати складні математичні формули. А вони в CSS дійсно складні, хоча б через свій синтаксис, але шо тут вже вдієш. Виглядають вони приблизно ось так:

@function --fluid-size(--min, --max) {
  result: clamp(var(--min), 2vw + 1rem, var(--max));
}
…
font-size: --fluid-size(1rem, 3rem);

Синтаксис простий: - Оголошуємо через at-rule @function; - Назва має префікс --, як і решта синтаксису для користувацьких властивостей в CSS; - Функція може приймати параметри; - Параметри можуть мати значення за замовчуванням: --fn(--x: 1px) {…}; - Параметри можна типізувати: --fn(--clr <color>) {…} - Параметр може бути списком: --fn(--list <length>#), width: --fn({1px, 7px, 2px}) (саме так, з фігурними дужками); - Ключове слово result є, по суті, відповідником нашого улюбленого return; Можна навіть писати досить складну (наскільки це можливо) логіку. Наприклад, створювати проміжні змінні з власними розрахунками чи просто як константи:

@function --fluid-size(--min: 1rem, --max: 3rem) {
  --preferred: calc(2vw + 1rem);
  --safe-min: max(var(--min), 0.875rem);

  result: clamp(var(--safe-min), var(--preferred), var(--max));
}

Ба більше, користувацькі функції підтримують медіа-запити:

@function --narrow-wide(--narrow, --wide) {
  result: var(--wide);
  @media (width < 700px) {
    result: var(--narrow);
  }
}

та умовну функцію if(), яку варто розібрати окремо. Що по підтримці? Ну, поки трошки сумно. Реалізацію поточного драфту для custom functions викотив Chromium, що означає, що ми можемо спробувати цей синтаксис в Chrome, Edge та решті хроміум-зоопарку. Firefox, як і завжди, певно не спішитиме з імплементацією допоки стандарт не перейде до стабільнішого рівня, а щодо Safari впевненим можна бути лише в одному — що ми не можемо бути в ньому впевненими. Я, насправді, дуже чекаю коли CSS custom functions увійдуть до Baseline, бо це, насправді, дуже зручна можливість. До речі, рука в руку з ними йде й чернетка CSS mixins, на які я теж чекаю. Про міксіни поговоримо згодом, коли до них дійдуть руки хоча б у Chromium, але маю сподівання, що чекати лишилося недовго. Чого я з таким нетерпінням чекаю на момент, коли ці специфікації увійдуть до Baseline? Бо це означатиме початок забуття SCSS та всіляких інших LESS, до яких я відчуваю безпідставну та пекучу неприязнь. А якщо цей допис набере бодай 100 реакцій, то я розповім чому. А як не набере, то не розповім. @babichdev *** Що почитати: MDN: @function CSS at-rule MDN: Using CSS custom functions Що почитати душнілам: W3C: CSS Functions and Mixins Module P.S. Товариство, дуже сподіваюсь, що у вас все добре, наскільки це може бути. Росія — кончена країна кончених людей. Тримаймося.

Доброго ранку, товариство. Так, ніби з поїздками поки все, але від того мій розклад щось не стає легшим. Навпаки, я тепер вдома буду як електровіник крутитися. Поки очухуюсь від ФанКону, пробую зібрати докупи усе, що маю зробити і написати, тому, швидше за все, нічого не буду робити і писати, а буду сумно прокрастинувати, уявляючи, як я все роблю і пишу. Але тим не менш. Цього четверга запрошую вас на перші лампові дебати у Львові: https://t.me/it_lampa/61 Я там буду модератором. І що супер важливо: квитків усього 20, лишилося усього 7, більше не буде, і запису не буде, і стриму не буде. Ексклюзив, в общім. Буду радий вас бачити!

Вперше за кілька років їду до Києва не в дивовижно-веброзробницьких справах, а просто по фану. Якщо точніше — на ФанКон ) Як раптом побачите мене там, не соромтесь, підходьте ) А тим часом ви можете добити мені дві тисячі переглядів на "Одне питання — три відповіді". Можете ж? Можете? Всім гарного завершення тижня і спокійних вихідних!

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

Новий випуск "Одне питання — трив відповідь" уже на каналі! https://youtu.be/IESsvnPfPtU ОБОВ'ЯЗКОВО: вподобайка, коментар і поширення. А то забаню всіх. Приємного перегляду!

Я розпочав карʼєру у веброзробці 2011 року. Здається, це було не так давно, але минуло вже 15 років. Парадокс у тому, що світ тоді не виглядав аж таким далеким від сьогоднішнього: уже був інтернет, смартфони, макбуки й інші звичні нам технологічні радощі. Тому ці півтора десятиліття й не відчуваються як півтора десятиліття — радше як кілька дуже насичених років. Можливо, саме через це розробка досі сприймається як щось дуже нове. Ніби ми живемо ледь не на світанку галузі, а більшість продуктів, якими користуємося, зʼявилися буквально нещодавно. Але іноді дуже цікаво задуматись — а коли зʼявилися ті продукти, програми, якими ми користуємось ледь не щодня, ну або принаймні дуже активно користувалися донедавна. Наприклад, моєю першою роботою, повʼязаною з компʼютерами, був веб дизайн. Очевидно, що тоді (а це плюс-мінус 2006-2011 роки) все малювалося у фотошопі, який я запускав щодня, аби намалювати черговий сайт-візитку. І хіба міг 20-річний я навіть здогадуватися, що мій повсякденний інструмент зʼявився тоді, коли я ходив до радянського дитсадочку? Так-так, саме радянського, бо перша версія Adobe Photoshop зʼявилася у лютому 1990 року. Ба більше, другий їхній продукт, яким я користувався паралельно з фотошопом, взагалі старший за мене на кілька місяців. До вашої уваги — Adobe Illustrator, 19 березня 1987 року. Рухаємося далі. Я не уявляю собі людини, яка за віком може бути моєю колегою по роботі, що в житті не чула про Microsoft Word та Excel. Ці два продукти є де-факто стандартом в багатьох галузях, успішно витримавши конкуренцію як від хмарних продуктів, так і від опенсорсних аналогів. Їх досі викладають в школах. А зʼявилися вони… Excel виходить 1985 року, тоді ж, коли в совєтському союзі розпочинається "пєрєстройка". Яка в свою чергу стала одним з каталізаторів розвалу цієї недоімперії. От би й в 2026 році Microsoft випустили щось, що через сову на глобус призведе до розпаду Росії… А Microsoft Word побачив світ 1983 року, практично одночасно з підключенням четвертого енергоблоку ЧАЕС до мережі. Гм, у мене починає зʼявлятися думка, що усі ці події якось повʼязані між собою… Але сова чогось не погоджується. Пірнаємо глибше? Тоді зануримося у 70-і роки. Несподівано, так? 1979 року, коли мій тато працює на будові і отримує зарплату у віконечку, компанія RSI випускає Oracle V2, що стала першою комерційною SQL-базою даних. Хоча й у нас тоді відбувалися примітні події — до прикладу, вийшла кінострічка "Вавілон ХХ" Івана Миколайчука, яка нині посідає 10 місце у топ-100 українських фільмів у рейтингу "Довженко-Центру". І тут ви такі "ШООООО?! Який такий SQL?!". Ну так. SQL. Першу версію якого, під назвою SEQUEL (а ви думали це прикол такий?), було описано IBM Research 1974 року (повноцінно стандартом SQL став, щоправда, аж у 1986). Що ще цікавого відбулося цього року? Славнозвісний Watergate і відставка Ніксона. Та, були часи, політики йшли у відставку через скандали, уявіть собі таке… Копнути ще разочок? Добре. Але разочок. І цього разу нам доведеться відвідати… Місяць. І тут ви такі "ШООООО?! Який такий Місяць?! Забув таблетки випить?". Таблетки то я забув випить, але поки, дякувати богу, ще не ті. А на Місяць ми з вами летимо разом з екіпажем Apollo 11, члени якого стали першими в історії представниками людства, що ступили на інше небесне тіло. І поки 20 липня 1969 усі, затамувавши подих, слідкували за висадкою астронавтів, у нетрях Bell Labs Кен Томпсон писав перші (а може й не перші) рядки коду операційної системи, яка згодом стала відомою як UNIX. І це я оглянув лише декілька прикладів програмних продуктів, якими ми усі користуємося в тому чи іншому вигляді й досі. Якщо придивитися уважніше, то виявиться, що не так уже й довго лишилося до першого сторіччя першого рядочку коду, написаного високорівневою мовою. Програмування існувало задовго до нас, і, хочеться вірити, існуватиме довго після нас.

#нове_відео Товариство, нове відео вже на каналі! Розмовляв з Ігорем Закутинським, CTO в FORMA, про масштабування глобальних продуктів з України, AI у щоденній роботі CTO та про те, чому наступне десятиліття української tech-індустрії може стати визначальним для світу. З вас вподобайки, коментарі та поширення. Приємного перегляду! https://youtu.be/lIugEWpCzX4

Фреймворк-абізянство — це такий особливий спосіб мислення, коли навіть hover робиться через setState. І так, я цей приклад не вигадав, я бачив такий код в проді. А от як назвати протилежне мислення, я ще не знаю. Суть його полягає в тому, що замість робити ВСЕ на умовному реакті, спочатку треба трошки подумати — "а може HTML/CSS/JS вже самі таке вміють?". Дивіться, я тут останнім часом ношусь і з dialog, popover, @layout, @scope, всякими приколами з Browser API, що аж примудрився зібрати цілком собі робочий застосунок чисто на нативці. І поки я робив ту альфа-версію, усе частіше ловив себе на думці, що величезну кількість речей ми досі робимо максимально складно. Просто за звичкою. Я якось сів і почав прикидати, що можна теоретично викинути або зробити по іншому в будь-якій бібліотеці компонент. І перше, що спадає на думку — усілякі тултипи, таби, закривайки-випадайки і тому подібний дрібʼязок чудово робляться за доповогою нативних елементів. А що не дуже робиться, то для того є Custom Elements. Готуючись до доповіді на fwdays, я зрозумів одну цікаву річ — коли мова йде про нативні вебкомпоненти, усі думають про страшний Shadow DOM, з усіма його ізоляціями, інкапсуляціями, шаблонами та іншими страхіттями. Хтось просто боїться класів. Ну але то таке. Річ у тім, що нам геть не обовʼязково використовувати Shadow DOM і мудохатися з ізоляцією стилів. Custom Elements чудово себе почувають в так званому Light DOM (неофіційна назва), коли вони виступають просто такою собі обгорткою для відкритого фрагменту дерева. Так от. Custom Elements виявились дуже зручними для невеличких "тупих" компонентів, задачею яких є якийсь простенький функціонал, наприклад, перемикання активного елемента всередині в залежності від значення атрибуту. Чи той же collapse/expand, але з зовнішнім керуванням. У мене взагалі є компонентик, який просто показує поточний слайд у вигляді "7/8", склеюючи два значення докупи. В чому ж, на мою думку, вигода? По-перше, Custom Elements підтримуються сьогодні будь-яким відром. По-друге — сумісність. Ваш фреймворк не зможе відрендерити Custom Element лише в одному випадку — він не вміє рендерити усі інші теги. По-третє — зменшення залежності на внутрішні приколи вашого стеку, кастомні елементи залежать тільки на вебстандарти і бравзери. По-четверте — якщо засукати рукави і перенести всі банальні й прості рішення з фреймворку на Custom Elements, то можна нічогенько так скоротити фінальний розмір бандлу. Загалом, ідея цього допису полягає в тому, щоб за нагоди почати практикувати таку собі трирівневу систему прийняття рішень при створенні нового компонента: 1. Чи вміє це HTML/CSS/JS? Ви будете приємно здивовані тим, скільки всього сьогодні вміє платформа. Я й сам час від часу роблю для себе приємні відкриття, буду відвертим. Загалом, якщо вам треба щось просте, спочатку пошукайте, чи нема такого вже в бравзері. 2. Чи треба мені для цього мій фреймворк? Нативна платформа, хоч і вміє вже багато, усе ж дає нам радше кубики з леґо аніж готові рішення. І часто рішення треба зібрати самим. Але тут теж є певний простір для маневру — часто певні рішення цілком собі складаються докупи без залучення додаткової складності. Ті самі Custom Elements — це той шар, який дозволяє зібрати певний функціонал, надаючи вам і реактивність, і інструменти для DOM, і події, і команди, і ще купу всього просто з коробки. 3. Чи можу я не все зробити з фреймворком? Тут більше задача на декомпозицію. Часто, дійсно, новий компонент може видаватися складним, залежним на глобальні стани, завʼязаним на інші компоненти і так далі. Але, якщо подихати носом і подивитися зі сторони, можна побачити як страшна велика задача розкладається на оберемок маленьких нестрашних. І тоді ми можемо спокійно повертатись до питання №1. Я би радив спробувати розглядати ваш фреймворк як такий собі оркестратор, який відповідає за складні композитні задачі, а прості речі він віддає на відкуп бравзеру і вашим знанням платформи. Якщо спробувати зібрати це все в один афоризм — не сапайте вазони комбайнами. @babichdev

Товариство, маю чудові новини. Усіма правдами й неправдами вдалося вчасно дозібрати необхідні кошти на РЕБ для 115 ОМБр, і сьогодні я оплатив решту рахунку. Щойно отримаю світлини від бійців, відзвітую окремим дописом. Дякую усім, хто долучився бодай гривнею! Але навіть не думайте питати, на що мені довелося піти, аби закрити збір вчасно. *** До речі, ще можна взяти участь у розіграші квитка на AI JavaScript fwdays'26, що відбудеться 23 травня. Умови прості — донатьте від 200 гривень і беріть участь в розіграші. Квиток розіграю завтра. Кошти, залучені цим розіграшем, підуть на наступний збір. 🔗Посилання на банку https://send.monobank.ua/jar/CKBtmw5Ya 💳Номер картки банки 4874100037660035 Якщо ж не терпиться взяти квиток вже, то ось вам промокод на 15% — 73D6A13895

Київ, булочка з маком і Карпати. Люблю життя за непередбачуваність. Цього року обставини складалися так, що я не мав бути присутнім на DOU DAY взагалі. А склалися таким чином, що я мало того, що був, то ще й обидва дні мав місце в програмі. Мені подобаються події від DOU не самим розмахом (хоча за це їм окрема повага), а радше розмаїттям можливостей до спілкування, до нових несподіваних знайомств, до неочікуваних зустрічей. До речі, саме так я познайомився з прекрасними людьми з Headway, Appflame, Obrio, Universe та іншими, завдяки яким мій ютуб настільки змінився за останній рік. Це так, до слова. Так, я їжджу на DOU в першу чергу за новими знайомствами. Не за контактами, а саме за знайомствами. І мені дуже імпонує, що DOU збирають в одному місці настільки різних людей з різних галузей. Взагалі, я на конференції раджу усім ходити в першу чергу заради нетворкінгу та нових знайомств. А ще мені дуже подобається, що там є величезна купа людей, які в упор не знають, хто я такий. Воно трохи приземляє, знаєте ) Корисно для таких мікрознаменитостей, як я ) В перший день я робив, не знаю, воркшоп — не воркшоп, лекцію — не лекцію, в общім намагався розказати про один маленький, але дуже гордий проєктик, який я написав ось цими самими руками без всяких ваших фреймворків. Там було і про Custom Elements, і про всякі нові й не дуже приколи CSS та JS, і про Browser API, і про усілякі цікаві трюки. І якщо перед цим воркшопом я жартував, що мені на нього треба шість годин, а не півтори, то під час нього я зрозумів, що це був геть не жарт. Мені реально не вистачило часу бодай поверхнево розповісти про усе, що я хотів. Тому думаю тепер, як це його зібратися докупи і якісь статті написати, чи шо. А в суботу я записував подкаст з Вірою Ткаченко, CTIO в MacPaw. Я міг би говорити з нею про іновації, про ШІ, про ще якісь "гарячі" теми, але вирішив розмовляти про те, що цікаво мені. А цікаво мені було дізнатися більше не про CTIO, а про людину за цією посадою. І вийшло дуже цікаво й душевно. Зокрема говорили про жінок в ІТ, і для мене, як батька двох дочок, такі теми є дуже важливими. А ще дуже важливим є те, щоб в кожній галузі для них були такі приклади для наслідування, як Віра. Запис, до речі, вийде на ютубі свого часу. А ввечері був концерт Жадана і всілякі розваги, проте я на них не потрапив. Чому? Тому, що конференції конференціями, популярність популярністю, але якщо я пообіцяв сину поїхати з ним в шкільну поїздку в Карпати — значить я маю їхати в шкільну поїздку в Карпати. Навіть якщо для цього треба міняти квитки і їхати пів дня в Інтерсіті, аби бути ввечері вдома. Бо посеред усього двіжу, посеред постійної метушні, посеред постійних зйомок, мітапів, конференцій та інших атракцій надзвичайно важливо памʼятати, що насправді важливе лише те, що ми робимо для своїх близьких.

Мем на злобу дня, як то кажуть