Як "вимкнути" частину форми?
Доволі часто перед нами постає задача "вимкнути", або ж задізейблити відразу цілу частину форми, а не один якийсь інпут. Не знаю, як ви, а я часто вимикав усі контроли по одному.
А виявляється, що це можна зробити за допомогою атрибуту disabled елемента fieldset! Якщо встановити значення цього артибуту у правдиве значення, то усі вкладені в цей fieldset інтерактивні елементи заблокуються. І інпути, і кнопки, і селекти. Все.
Але існує запасне рішення на той випадок, якщо вам потрібно, до прикладу, залишити якийсь елемент активним. Наприклад, кнопку "Редагувати". Тоді ви можете її помістити до вкладеного legend, всередині якого закони й правила не діють. Ну, як мінімум, батьківський disabled ігнорується.
Мені ця фіча точно стане в нагоді, а що скажете на це ви? Чи мали в практиці випадки, коли це могло б спростити ваш код? Розкажіть!
@babichdev
Цікаво? Корисно? Тисни вподобайку та ділися дописом з друзями та колегами!
Доволі часто перед нами постає задача "вимкнути", або ж задізейблити відразу цілу частину форми, а не один якийсь інпут. Не знаю, як ви, а я часто вимикав усі контроли по одному.
А виявляється, що це можна зробити за допомогою атрибуту disabled елемента fieldset! Якщо встановити значення цього артибуту у правдиве значення, то усі вкладені в цей fieldset інтерактивні елементи заблокуються. І інпути, і кнопки, і селекти. Все.
Але існує запасне рішення на той випадок, якщо вам потрібно, до прикладу, залишити якийсь елемент активним. Наприклад, кнопку "Редагувати". Тоді ви можете її помістити до вкладеного legend, всередині якого закони й правила не діють. Ну, як мінімум, батьківський disabled ігнорується.
<fieldset disabled>
<legend>
Legend
<button>Edit</button>
</legend>
<input>
<button>Click me</button>
</fieldset>
Мені ця фіча точно стане в нагоді, а що скажете на це ви? Чи мали в практиці випадки, коли це могло б спростити ваш код? Розкажіть!
@babichdev
Цікаво? Корисно? Тисни вподобайку та ділися дописом з друзями та колегами!
🔥95👏5❤4
#ДонатНаРЕБ
Збір для 109 ОГШБ 10 ОГШБр "Едельвейс"
Друзі, потрібно зібрати 100 000 гривень для дооплати засобу радіоелектронної боротьби для 109 окремого гірсько-штурмового батальйону. Більшу частину рахунку вже сплачено — залишилось добити фінал.
Щоб заохотити вас долучатися трохи активніше — я запускаю розіграш! За кожні 50 гривень донату ви отримуєте шанс виграти один із подарунків:
🎁 Пазл GoodLoot "Witcher: Griffin Fight"
Подарунок від мене особисто
🎯 Мета: 20 000 грн
🎁 Клавіатура R-Go Compact Break
Від друзів з ERGO PLACE
🎯 Мета: 50 000 грн
🎁 LEGO Dune Atreides Royal Ornithopter
Від української продуктової IT-компанії Brainstack
🎯 Мета: 100 000 грн
Щойно досягаємо відповідної мети — розігрую черговий подарунок серед усіх донатерів за допомогою monobank.
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
Памʼятайте: не існує замалих донатів.
Кожен ваш внесок — це ще один збитий дрон.
Ще одне збережене життя.
Ще один крок до Перемоги.
Збір для 109 ОГШБ 10 ОГШБр "Едельвейс"
Друзі, потрібно зібрати 100 000 гривень для дооплати засобу радіоелектронної боротьби для 109 окремого гірсько-штурмового батальйону. Більшу частину рахунку вже сплачено — залишилось добити фінал.
Щоб заохотити вас долучатися трохи активніше — я запускаю розіграш! За кожні 50 гривень донату ви отримуєте шанс виграти один із подарунків:
🎁 Пазл GoodLoot "Witcher: Griffin Fight"
Подарунок від мене особисто
🎯 Мета: 20 000 грн
🎁 Клавіатура R-Go Compact Break
Від друзів з ERGO PLACE
🎯 Мета: 50 000 грн
🎁 LEGO Dune Atreides Royal Ornithopter
Від української продуктової IT-компанії Brainstack
🎯 Мета: 100 000 грн
Щойно досягаємо відповідної мети — розігрую черговий подарунок серед усіх донатерів за допомогою monobank.
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
Памʼятайте: не існує замалих донатів.
Кожен ваш внесок — це ще один збитий дрон.
Ще одне збережене життя.
Ще один крок до Перемоги.
🔥12❤3
Гра у хованки
Одна з найпоширеніших задач в розробці інтерфейсів — тимчасово приховати той чи інший елемент. І рішення, здавалось би, очевидне — зробити
Ну, в більшості випадків може й так, але чи універсальне це рішення? Давайте спробуємо розібратися.
Приховати елемент можна у кілька способів, і вже згаданий
А є
Чи згадати тоді про атрибут
А ви як, користуєтесь цими можливостями, чи не задумуючись, просто викидаєте елемент з DOM?
@babichdev
***
Приєднуйтесь до збору на РЕБ та вигравайте чудові подарунки від мене та моїх друзів!
Одна з найпоширеніших задач в розробці інтерфейсів — тимчасово приховати той чи інший елемент. І рішення, здавалось би, очевидне — зробити
display: none, та й по всьому.Ну, в більшості випадків може й так, але чи універсальне це рішення? Давайте спробуємо розібратися.
Приховати елемент можна у кілька способів, і вже згаданий
display: none впевнено утримує першість. Коли ми застосовуємо цю властивість до елементу, він "зникає" з потоку документа, припиняючи брати участь в побудові рендер-дерева і, відповідно, візуального макету сторінки, так званого layout. При цьому з DOM він нікуди не зникає. Якщо коротко, то display: none прибирає усі видимі сліди присутности елемента.А є
visibility: hidden. І тут постає питання — а в чому ж різниця? А різниця в тому, що ця властивість прибирає лише відображення елемента, але його місце в render tree та layout зберігається. На сторінці при цьому утворюється "дірка" на місці цього елемента.display: none нагадує магічний трюк зі зникненням, але з кінострічки "Престиж": елемент дійсно зникає, не припиняючи свого існування. Чи?.. Але це вже інше питання. А от visibility: hidden це як той же трюк, але в актовій залі вашої школи: елемент від вас просто затуляють білим простирадлом, усі знають, що він там, а крайні ряди навіть можуть трошки його побачити.Чи згадати тоді про атрибут
hidden? Хіба побіжно. Бо це просто ще один спосіб приховати за допомогою <div hidden> чи el.hidden = true. Але тільки у тому випадку, якщо ви не перевизначили стилі для селектора [hidden], який браузери за замовчуванням стилізують як display: none. А ви можете, я знаю.А ви як, користуєтесь цими можливостями, чи не задумуючись, просто викидаєте елемент з DOM?
@babichdev
***
Приєднуйтесь до збору на РЕБ та вигравайте чудові подарунки від мене та моїх друзів!
❤53🔥13🤔6👏3
Друзі, запрошую вас на Стрим для своїх №3!
Що це? Це затишно й по-дружньому проведений разом з вами вечір неділі і чудова нагода поставити мені запитання, на яке я можу дати як розлогу відповідь, варту цілого відео, так і вкластися в одне речення )
Досі тривожить, чи прийдесіренький вовчок ШІ і забере роботу? Цікавить, чому я не вважаю React найкращим у світі інструментом? Хочете зрозуміти, як рухатись далі в карʼєрі? Словом — питайте мене що завгодно, а я з радістю відповім вам наживо уже цієї неділі, 1 червня, о 18:00 на закритому Стримі для своїх!
Тож готуйте свої питання і реєструйтесь. До речі, реєстрація потрібна лише для того, аби ви могли додати подію до свого календаря. Я поки ніяких розсилок не планую ) Поки ;)
Чекатиму на вас!
Стрим для своїх №3
01 червня 2025, 18:00
Реєструйтесь тут: https://streamyard.com/watch/rYCqYEfzf5x9
А ще під час стриму я розіграю позачерговий подарунок за донати у зборі на РЕБ.
Що це? Це затишно й по-дружньому проведений разом з вами вечір неділі і чудова нагода поставити мені запитання, на яке я можу дати як розлогу відповідь, варту цілого відео, так і вкластися в одне речення )
Досі тривожить, чи прийде
Тож готуйте свої питання і реєструйтесь. До речі, реєстрація потрібна лише для того, аби ви могли додати подію до свого календаря. Я поки ніяких розсилок не планую ) Поки ;)
Чекатиму на вас!
Стрим для своїх №3
01 червня 2025, 18:00
Реєструйтесь тут: https://streamyard.com/watch/rYCqYEfzf5x9
А ще під час стриму я розіграю позачерговий подарунок за донати у зборі на РЕБ.
StreamYard
Стрим для своїх №3
You've been invited to join this webinar!
🔥21❤6
Гра в хованки 2: Швидкодія завдає удару у відповідь
В коментарях до попереднього допису про display vs visibility ви ніби жартома згадали opacity. Чи не згадав я про нього незаслужено? Дивіться, цей спосіб вирізняється однією суттєвою деталлю: навіть будучи повністю "невидимим", а по факту просто прозорим, елемент повністю зберігає всю інтерактивність — фокусабельність, події клавіатури й миші, а ще залишається повністю "видимим" скрінрідерів.
І зі скрінрідерами така історія, що майже усі способи направду сховають елемент від них, окрім того самого opacity. З ним вам доведеться вручну додавати атрибут aria-hidden. Тому жарти жартами, а a11y в сучасному світі треба знати й практикувати.
А що зі швидкодією?
Ховаючи елемент, нам важливо знати дві речі: як він поводитиметься зі скрінрідерами та скільки "коштуватиме" його відновлення.
І на це впливає в першу чергу те, чи викликатиметься reflow — процес перерахунку макету з видимих елементів. Цей процес насправді надзвичайно легко викликати, достатньо змінити будь-яку властивість елемента, що відповідає за його "фізичну" поведінку: розміри чи відступи. Ну і, очевидно, display.
Не вдаючись в подробиці, зазначу, що цей процес тим затратніший, чим більше у вас елементів у render-tree. Однак при цьому не найзатратніший, бо при цьому не змінюється DOM.
А от visibility та opacity reflow не викликатимуть, бо вони не змінюють жодних "фізичних" параметрів елемента, тож їх застосування викличе лише repaint. А він, у свою чергу, достатньо швидкий і давно дуууже сильно оптимізований бравзерами.
DOM оновлювати дорого
А от якщо ви любите стріляти по горобцях з BFG, то, швидше за все, ви користуєтесь "умовним рендерингом" вашого улюбленого фреймворку чи бібліотеки. Чи це погано, запитаєте ви? It depends, відповім я.
На маленьких і нечастих рендерах то вже бог з ним, там втрата тої швидкодії фактично непомітна. А от коли ви таке практикуєте на частих оновленнях, або на великій кількості елементів, то ось час вас присоромити.
Вся справа в тому, що умовний рендеринг зазвичай просто видаляє/вставляє елементи з DOM. І попри усі намагання оптимізувати ці процеси, маніпуляції з DOM були, лишаються й будуть найдорожчими в світі.
Майже кожна, навіть найменша зміна в DOM (а, тим паче, видалення/додавання елемента) потребує перевиконання повного циклу:
1. Оновити DOM
1¾. Оновити CSSOM (якщо змінили інлайн-стилі)
2. Оновити render-tree
3. Виконати reflow
4. Виконати repaint
Знову ж таки, оптимізації, батчинг, та-та, чули, знаєм. Але усе одно оновлення DOM — дороге. І викликатиме дуууже помітні лаги, якщо ви одночасно ховаєте або показуєте багато елементів.
У мене колись давно в практиці була задача з кастомним багаторівневим акордеоном, і виявилося, що ховати секції з display: none набагато швидше, аніж з класичним conditional rendering. Так, лаги усе одно були, але значно менші.
Тож підібʼємо підсумок: не всі "хованки" однаково корисні.
display: none і умовний рендеринг справді прибирають елемент із рендер-дерева, але коштом повної перебудови макету, а conditional rendering так і взагалі за рахунок зміни структури DOM. visibility: hidden і opacity: 0 лишають елемент у потоці, але поводяться зовсім по-різному з погляду доступности та взаємодії. Перший — неактивний і “німіє”, другий — поводиться як повноцінний видимий елемент, просто невидимий.
І лише розуміючи ці відмінності, можна ефективно керувати поведінкою інтерфейсу, не жертвуючи швидкодією та доступністю.
***
Ви вже долучилися до збору на РЕБ? Усього 50 гривень і шанс виграти класні подарунки — ваш!
В коментарях до попереднього допису про display vs visibility ви ніби жартома згадали opacity. Чи не згадав я про нього незаслужено? Дивіться, цей спосіб вирізняється однією суттєвою деталлю: навіть будучи повністю "невидимим", а по факту просто прозорим, елемент повністю зберігає всю інтерактивність — фокусабельність, події клавіатури й миші, а ще залишається повністю "видимим" скрінрідерів.
І зі скрінрідерами така історія, що майже усі способи направду сховають елемент від них, окрім того самого opacity. З ним вам доведеться вручну додавати атрибут aria-hidden. Тому жарти жартами, а a11y в сучасному світі треба знати й практикувати.
А що зі швидкодією?
Ховаючи елемент, нам важливо знати дві речі: як він поводитиметься зі скрінрідерами та скільки "коштуватиме" його відновлення.
І на це впливає в першу чергу те, чи викликатиметься reflow — процес перерахунку макету з видимих елементів. Цей процес насправді надзвичайно легко викликати, достатньо змінити будь-яку властивість елемента, що відповідає за його "фізичну" поведінку: розміри чи відступи. Ну і, очевидно, display.
Не вдаючись в подробиці, зазначу, що цей процес тим затратніший, чим більше у вас елементів у render-tree. Однак при цьому не найзатратніший, бо при цьому не змінюється DOM.
А от visibility та opacity reflow не викликатимуть, бо вони не змінюють жодних "фізичних" параметрів елемента, тож їх застосування викличе лише repaint. А він, у свою чергу, достатньо швидкий і давно дуууже сильно оптимізований бравзерами.
Я відчуваю гостру необхідність зануритись разом із вами в процес відображення сторінки бравзером, а саме розібрати усі ці дерева, та як вони між собою повʼязані. Що скажете? 100 вподобайок вистачить?
DOM оновлювати дорого
А от якщо ви любите стріляти по горобцях з BFG, то, швидше за все, ви користуєтесь "умовним рендерингом" вашого улюбленого фреймворку чи бібліотеки. Чи це погано, запитаєте ви? It depends, відповім я.
На маленьких і нечастих рендерах то вже бог з ним, там втрата тої швидкодії фактично непомітна. А от коли ви таке практикуєте на частих оновленнях, або на великій кількості елементів, то ось час вас присоромити.
Вся справа в тому, що умовний рендеринг зазвичай просто видаляє/вставляє елементи з DOM. І попри усі намагання оптимізувати ці процеси, маніпуляції з DOM були, лишаються й будуть найдорожчими в світі.
Майже кожна, навіть найменша зміна в DOM (а, тим паче, видалення/додавання елемента) потребує перевиконання повного циклу:
1. Оновити DOM
1¾. Оновити CSSOM (якщо змінили інлайн-стилі)
2. Оновити render-tree
3. Виконати reflow
4. Виконати repaint
Знову ж таки, оптимізації, батчинг, та-та, чули, знаєм. Але усе одно оновлення DOM — дороге. І викликатиме дуууже помітні лаги, якщо ви одночасно ховаєте або показуєте багато елементів.
У мене колись давно в практиці була задача з кастомним багаторівневим акордеоном, і виявилося, що ховати секції з display: none набагато швидше, аніж з класичним conditional rendering. Так, лаги усе одно були, але значно менші.
Тож підібʼємо підсумок: не всі "хованки" однаково корисні.
display: none і умовний рендеринг справді прибирають елемент із рендер-дерева, але коштом повної перебудови макету, а conditional rendering так і взагалі за рахунок зміни структури DOM. visibility: hidden і opacity: 0 лишають елемент у потоці, але поводяться зовсім по-різному з погляду доступности та взаємодії. Перший — неактивний і “німіє”, другий — поводиться як повноцінний видимий елемент, просто невидимий.
І лише розуміючи ці відмінності, можна ефективно керувати поведінкою інтерфейсу, не жертвуючи швидкодією та доступністю.
***
Ви вже долучилися до збору на РЕБ? Усього 50 гривень і шанс виграти класні подарунки — ваш!
❤75🔥9👏5
#цього_тижня ми з вами дізналися багато нового і зробили багато корисного! Дивіться самі:
— В понеділок спробували зрозуміти, що таке Symbol в JS;
— У вівторок продовжили подорож до Good Enough Code, розглянувши що таке diminishing returns;
— В середу дізналися, як вимикати відразу цілу частину форми з fieldset;
— В четвер нагадали собі про різні способи сховати елемент на сторінці;
— У пʼятницю ж відразу порівняли, які з них псують швидкодію найбільше;
А також розпочали збір на 100 000 гривень для 109 ОГШБ 10 ОГШБр "Едельвейс", — і кожен донат бере участь у розіграші подарунків!
***
А завершимо ми цей тиждень завтра на Стримі для своїх №3. Буду радий бачити кожного з вас!
— В понеділок спробували зрозуміти, що таке Symbol в JS;
— У вівторок продовжили подорож до Good Enough Code, розглянувши що таке diminishing returns;
— В середу дізналися, як вимикати відразу цілу частину форми з fieldset;
— В четвер нагадали собі про різні способи сховати елемент на сторінці;
— У пʼятницю ж відразу порівняли, які з них псують швидкодію найбільше;
А також розпочали збір на 100 000 гривень для 109 ОГШБ 10 ОГШБр "Едельвейс", — і кожен донат бере участь у розіграші подарунків!
***
А завершимо ми цей тиждень завтра на Стримі для своїх №3. Буду радий бачити кожного з вас!
🔥28❤7
Друзі, Стрим для своїх розпочнеться уже за лічені хвилини!
Відповідатиму на ваші питання, а ще зберемо кілька гривень на наш збір.
Ну і відмітимо успіх операції "Шалена бджілка" від СБУ ;)
Чекаю на вас!
P.S. Без реєстрації та СМС
Відповідатиму на ваші питання, а ще зберемо кілька гривень на наш збір.
Ну і відмітимо успіх операції "Шалена бджілка" від СБУ ;)
Чекаю на вас!
P.S. Без реєстрації та СМС
StreamYard
Стрим для своїх №3
You've been invited to join this webinar!
🔥10
Обіцянка-цяцянка, а потім — resolve
Promise давно вже міцно увійшов до нашої практики, а багато хто з вас навіть і не знає, як це — писати усе на вкладених колбеках. Та все ж більшість із нас продовжує писати код з "обіцянками" по-старому:
Тобто ми створюємо проміс, всередині робимо щось асинхронне, а тоді вже там же, всередині, і обробляємо результати виконання. Відверто, структурно це все ще схоже на маленький, але цілком відчутний callback-hell.
А як я вам скажу, що вже давно (і справді давно, включений до Baseline 2024 року) існує спосіб писати подібний код у більш структурованому, імперативному стилі? Дивіться:
Тут створюється порожній проміс і зберігаються посилання на resolve/reject. Що це дає? Місце виклику resolve/reject (наприклад, setTimeout) може бути деінде, ба більше, ви можете спокійно повертати чи передавати їх куди заманеться. Коли логіка створення проміса й обробки його результату відокремлені, код стає набагато гнучкішим.
Такий підхід згодиться, коли треба створити проміс зараз, а виконати його пізніше — наприклад, у зовнішньому евент-хендлері чи колбеках.
Promise.withResolvers не робить нічого революційного, по суті він є синтаксичним цукром для популярного патерна з “зовнішнім” resolve/reject:
Навіщо це особисто вам:
— Promise.withResolvers() — це зручний і безпечний спосіб створити проміс із доступом до resolve/reject ззовні;
— Він не привносить нової складности, навпаки просто формалізує та спрощує те, що ми й так давно робили руками;
— Дозволяє писати чистіший, зрозуміліший та структурованіший код, особливо у випадках, де логіка розірвана в часі.
Мені особисто дуже зайшло використовувати withResolvers, хоча б через дещо інший спосіб організації коду.
MDN
А ви як? Спробували би це у своєму проді? Чи може встигли вже? Розкажіть в коментарях!
@babichdev
***
👋 Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває! Ми вже подолали першу позначку в 20 000 і впевнено йдемо до 50 000 грн! Кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
Promise давно вже міцно увійшов до нашої практики, а багато хто з вас навіть і не знає, як це — писати усе на вкладених колбеках. Та все ж більшість із нас продовжує писати код з "обіцянками" по-старому:
const wait = (ms) =>
new Promise((resolve) => {
setTimeout(() => {
resolve('Готово!');
}, ms);
});
await wait(1000); // Через секунду → "Готово!"
Тобто ми створюємо проміс, всередині робимо щось асинхронне, а тоді вже там же, всередині, і обробляємо результати виконання. Відверто, структурно це все ще схоже на маленький, але цілком відчутний callback-hell.
А як я вам скажу, що вже давно (і справді давно, включений до Baseline 2024 року) існує спосіб писати подібний код у більш структурованому, імперативному стилі? Дивіться:
const { promise, resolve } = Promise.withResolvers();
setTimeout(() => {
resolve('Готово!');
}, 1000);
await promise; // → "Готово!"Тут створюється порожній проміс і зберігаються посилання на resolve/reject. Що це дає? Місце виклику resolve/reject (наприклад, setTimeout) може бути деінде, ба більше, ви можете спокійно повертати чи передавати їх куди заманеться. Коли логіка створення проміса й обробки його результату відокремлені, код стає набагато гнучкішим.
Такий підхід згодиться, коли треба створити проміс зараз, а виконати його пізніше — наприклад, у зовнішньому евент-хендлері чи колбеках.
Цей допис точно заслужив на твою вподобайку. От і постав її просто зараз ;)
Promise.withResolvers не робить нічого революційного, по суті він є синтаксичним цукром для популярного патерна з “зовнішнім” resolve/reject:
let resolve, reject;
const promise = new Promise((res, rej) => {
resolve = res;
reject = rej;
});
//
resolve();
Навіщо це особисто вам:
— Promise.withResolvers() — це зручний і безпечний спосіб створити проміс із доступом до resolve/reject ззовні;
— Він не привносить нової складности, навпаки просто формалізує та спрощує те, що ми й так давно робили руками;
— Дозволяє писати чистіший, зрозуміліший та структурованіший код, особливо у випадках, де логіка розірвана в часі.
Мені особисто дуже зайшло використовувати withResolvers, хоча б через дещо інший спосіб організації коду.
MDN
А ви як? Спробували би це у своєму проді? Чи може встигли вже? Розкажіть в коментарях!
@babichdev
***
Please open Telegram to view this post
VIEW IN TELEGRAM
❤109🔥25👏6
#партнерський_допис
Я на 100% впевнений, що серед вас немає нікого, хто бодай раз не робив git push (чули ви про про нього то точно), після якого щось там крутиться, скрипить, зеленіє, червоніє, падає, встає — і от ваш код уже в “проді”, де тисячі користувачів тиснуть ту саму “зільону кнопку”.
А ви цікавилися, що ж там скрипить-рипить і падає після пушу? Чи знаєте, як налаштувати хоча б простий CI/CD? А що, коли пайплайни почнуть падати один за одним — зрозумієте, в чому причина?
Я не кажу, що всі мають ставати DevOps-інженерами, але знати ці основи — то вже базова частина навичок розробника. Ваших навичок.
Саме тому щиро раджу подію, на якій ви дізнаєтеся трошки більше, а саме
DevOps: Від Кодування до Хмари — безкоштовний мітап від Sigma Software University.
📅 3 червня, 18:30
🌐 Онлайн
🎯 У програмі: Linux, Git, Docker, AWS, CI/CD — і головне, практичний кейс, де все це працює разом.
Цей мітап буде корисним для тих, хто хоче бачити свою роботу системніше, а особливо — мідлам, які прагнуть стати синьйорами, а не просто записати в резюме черговий фреймворк.
✅ РЕЄСТРАЦІЯ НА МІТАП
.
Я на 100% впевнений, що серед вас немає нікого, хто бодай раз не робив git push (чули ви про про нього то точно), після якого щось там крутиться, скрипить, зеленіє, червоніє, падає, встає — і от ваш код уже в “проді”, де тисячі користувачів тиснуть ту саму “зільону кнопку”.
А ви цікавилися, що ж там скрипить-рипить і падає після пушу? Чи знаєте, як налаштувати хоча б простий CI/CD? А що, коли пайплайни почнуть падати один за одним — зрозумієте, в чому причина?
Я не кажу, що всі мають ставати DevOps-інженерами, але знати ці основи — то вже базова частина навичок розробника. Ваших навичок.
Саме тому щиро раджу подію, на якій ви дізнаєтеся трошки більше, а саме
DevOps: Від Кодування до Хмари — безкоштовний мітап від Sigma Software University.
📅 3 червня, 18:30
🌐 Онлайн
🎯 У програмі: Linux, Git, Docker, AWS, CI/CD — і головне, практичний кейс, де все це працює разом.
Цей мітап буде корисним для тих, хто хоче бачити свою роботу системніше, а особливо — мідлам, які прагнуть стати синьйорами, а не просто записати в резюме черговий фреймворк.
.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17🔥9
Свою першу справжню робочу таску я памʼятатиму, певно, усе життя. В одній точці часу-простору зійшлися з однієї сторони моя абсолютна недосвідченість та самовпевненість, а з іншої — якась просто непомірна задача, поставлена тімлідом, який виявився за сумісництвом моїм бувшим однокурсником.
Це був далекий 2011 рік, iPad видавався інопланетною технологією, а тач-інтерфейс я вперше в житті побачив за два дні до першого робочого дня. На співбесіді. І моя перша в житті таска була… була моя перша в житті таска…
Моїм повним фіаско. Дивіться самі — мені треба було зробити:
— Пінч-зум! (це коли ви два пальці то докупи, то врізнобіч робите)
— Під Safari! (очевидно, але я його бачив вперше в житті)
— На айпаді! (з віддаленим дебагом і нині справи не дуже, а тоді й поготів)
— …і фінальний акорд — на jQuery!
Очевидно, що я не те, що не впорався із задачею, я за повні робочі 8 годин (сам в шоці, що колись прямо по табелю працював) встиг знаєте, що зробить? Ніколи не здогадаєтесь.
За 8 годин я зміг отримати координати тапа, тобто куди пальцем в екран тикнуто. І так, лише для одного. Задачу було епічно й з тріском провалено. І її у мене, очевидно, забрали. Я, до речі, не памʼятаю, чи вона взагалі колись була доведена до кінця, бо вже дуже скоро ми відмовилися від jQuery на користь Zepto, а за тим швидко прийшов наш власний фреймворк.
Так от. Який я урок з цього виніс? Згадуючи ті часи, я тепер чітко розумію — ні-я-ко-го. Бо я був самовпевнений впертюх, який в жодному разі не піде й не запитається когось більш досвідченого, і буде самотньо посеред повного кабінету людей намарно намагатися досягти хоч якогось результату. І ще довго наступав на величезні граблі, зроблені з переоцінки моїх власних можливостей.
Ця задача запамʼяталася мені з багатьох причин. Не все варто зараз розбирати в деталях, але одну річ я засвоїв точно — іноді ти просто не справляєшся. І це нормально. Тут головне зробити правильні висновки і перетворити "невдачу" на поживний ґрунт для особистого професійного росту.
Не будьте як я у 2011-му: впертим, мовчазним та переконаним, що зобовʼязаний усе знати наперед. Будьте як ви у 2025-му — жваві, допитливі, та іноді трооошечки набридливі ;)
✅ @babichdev
***
Більше гривень — більше подарунків! Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває, і ми впритул наблизились до другої мети в 50 000 грн! Кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
Це був далекий 2011 рік, iPad видавався інопланетною технологією, а тач-інтерфейс я вперше в житті побачив за два дні до першого робочого дня. На співбесіді. І моя перша в житті таска була… була моя перша в житті таска…
Моїм повним фіаско. Дивіться самі — мені треба було зробити:
— Пінч-зум! (це коли ви два пальці то докупи, то врізнобіч робите)
— Під Safari! (очевидно, але я його бачив вперше в житті)
— На айпаді! (з віддаленим дебагом і нині справи не дуже, а тоді й поготів)
— …і фінальний акорд — на jQuery!
Очевидно, що я не те, що не впорався із задачею, я за повні робочі 8 годин (сам в шоці, що колись прямо по табелю працював) встиг знаєте, що зробить? Ніколи не здогадаєтесь.
За 8 годин я зміг отримати координати тапа, тобто куди пальцем в екран тикнуто. І так, лише для одного. Задачу було епічно й з тріском провалено. І її у мене, очевидно, забрали. Я, до речі, не памʼятаю, чи вона взагалі колись була доведена до кінця, бо вже дуже скоро ми відмовилися від jQuery на користь Zepto, а за тим швидко прийшов наш власний фреймворк.
Так от. Який я урок з цього виніс? Згадуючи ті часи, я тепер чітко розумію — ні-я-ко-го. Бо я був самовпевнений впертюх, який в жодному разі не піде й не запитається когось більш досвідченого, і буде самотньо посеред повного кабінету людей намарно намагатися досягти хоч якогось результату. І ще довго наступав на величезні граблі, зроблені з переоцінки моїх власних можливостей.
Ця задача запамʼяталася мені з багатьох причин. Не все варто зараз розбирати в деталях, але одну річ я засвоїв точно — іноді ти просто не справляєшся. І це нормально. Тут головне зробити правильні висновки і перетворити "невдачу" на поживний ґрунт для особистого професійного росту.
Не будьте як я у 2011-му: впертим, мовчазним та переконаним, що зобовʼязаний усе знати наперед. Будьте як ви у 2025-му — жваві, допитливі, та іноді трооошечки набридливі ;)
***
Більше гривень — більше подарунків! Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває, і ми впритул наблизились до другої мети в 50 000 грн! Кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤78🔥11
Дивовижний світ веброзробки
#партнерський_допис Я на 100% впевнений, що серед вас немає нікого, хто бодай раз не робив git push (чули ви про про нього то точно), після якого щось там крутиться, скрипить, зеленіє, червоніє, падає, встає — і от ваш код уже в “проді”, де тисячі користувачів…
Вітаю, колеги! Сьогодні допис буде тільки один, і він буде не про веброзробку.
Я хочу нагадати вам, що досі триває наш з вами збір для 109 ОГШБ 10 ОГШБр "Едельвейс". Потрібно зібрати 100 000 гривень для дооплати засобу радіоелектронної боротьби.
Миз вами вже майже подолали половину збору, тож треба трохи піднатиснути і довести його до кінця! Якщо кожен з вас закине бодай по 50 гривень, ми закриємо цей збір за мить!
Нагадую, що кожні ваші 50 гривень, задоначені на збір — це додатковий шанс виграти один з чудових подарунків:
🎁 Пазл GoodLoot "Witcher: Griffin Fight"
Подарунок від мене особисто
🎯 Мета: 20 000 грн (розіграно, чекаю на підтвердження)
🎁 Клавіатура R-Go Compact Break
Від друзів з ERGO PLACE
🎯 Мета: 50 000 грн
🎁 LEGO Dune Atreides Royal Ornithopter
Від української продуктової IT-компанії Brainstack
🎯 Мета: 100 000 грн
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
Дякую усім, хто долучається! І памʼятайте кожна гривня важлива.
Гарного та натхненного вам усім дня!
Я хочу нагадати вам, що досі триває наш з вами збір для 109 ОГШБ 10 ОГШБр "Едельвейс". Потрібно зібрати 100 000 гривень для дооплати засобу радіоелектронної боротьби.
Миз вами вже майже подолали половину збору, тож треба трохи піднатиснути і довести його до кінця! Якщо кожен з вас закине бодай по 50 гривень, ми закриємо цей збір за мить!
Нагадую, що кожні ваші 50 гривень, задоначені на збір — це додатковий шанс виграти один з чудових подарунків:
🎁 Пазл GoodLoot "Witcher: Griffin Fight"
Подарунок від мене особисто
🎯 Мета: 20 000 грн (розіграно, чекаю на підтвердження)
🎁 Клавіатура R-Go Compact Break
Від друзів з ERGO PLACE
🎯 Мета: 50 000 грн
🎁 LEGO Dune Atreides Royal Ornithopter
Від української продуктової IT-компанії Brainstack
🎯 Мета: 100 000 грн
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
Дякую усім, хто долучається! І памʼятайте кожна гривня важлива.
Гарного та натхненного вам усім дня!
❤15🔥4
DOCTYPE писати не треба!
Саме так я вважав досить тривалий час: ніби ж HTML5 і так тепер скрізь за замовчанням, бравзери розумні, самі розберуться, хіба ні?
Я не міг помилятися більше.
DOCTYPE — це особлива декларація, яка пояснює бравзеру, за яким саме стандартом треба обробляти конкретний документ. Сьогодні він має виглядати як
Раніше ж ця декларація мала наступний вигляд:
І вказувала який конкретно стандарт використовується і, мало того, містила пряме посилання на DTD, Document Type Definiton, набір інструкцій для бравзера, які описують як обробляти ті чи інши теги. Ці посилання активні й зараз, і ви можете почитати, що ж там такого пише.
Так от, а що ж станеться, якщо не вказати DOCTYPE?
Тоді буде увімкнено quirks mode: режим рендерингу, в якому імітується поведінка старих бравзерів для забезпечення сумісності з застарілими веб-сторінками. Це означає, що бравзер може відображати сторінку з помилками чи некоректно інтерпретувати сучасний CSS.
Це може призвести до багатьох "цікавих" наслідків, серед яких можлива неправильна обробка семантичних елементів, що може суттєво впливати на доступність, чи застосовуватись якісь CSS-хаки з доісторичних часів, через що непередбачувано попливуть ваші стилі, і ще всілякі інші сюрпризи.
І от саме тому вказувати DOCTYPE в документі зараз важливо, як ніколи, якщо ми хочемо, аби бравзер правильно обробляв його, ми могли використовувати найсучасніші можливості HTML та CSS, і нам не боліла голова через кросбравзерність (вірніше її відсутність). Якщо коротко — DOCTYPE це єдиний спосіб гарантувати, що бравзер працює в сучасному стандартному режимі, а не перетворюється на симулятор Internet Explorer 5.
Спробуйте відкрити свою стару верстку без <!DOCTYPE html> — і розкажіть в коментарях, наскільки все поїхало. Або не поїхало 😉
MDN: Understanding quirks and standards modes
@babichdev
***
Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває, і ми вже перетнули позначку в 50 000 грн! Нагадую, кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
Саме так я вважав досить тривалий час: ніби ж HTML5 і так тепер скрізь за замовчанням, бравзери розумні, самі розберуться, хіба ні?
Я не міг помилятися більше.
DOCTYPE — це особлива декларація, яка пояснює бравзеру, за яким саме стандартом треба обробляти конкретний документ. Сьогодні він має виглядати як
<!DOCTYPE html>, і цього цілком достатньо, аби бравзер знав — обробляти html треба за останнім писком моди.Раніше ж ця декларація мала наступний вигляд:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
І вказувала який конкретно стандарт використовується і, мало того, містила пряме посилання на DTD, Document Type Definiton, набір інструкцій для бравзера, які описують як обробляти ті чи інши теги. Ці посилання активні й зараз, і ви можете почитати, що ж там такого пише.
Так от, а що ж станеться, якщо не вказати DOCTYPE?
Тоді буде увімкнено quirks mode: режим рендерингу, в якому імітується поведінка старих бравзерів для забезпечення сумісності з застарілими веб-сторінками. Це означає, що бравзер може відображати сторінку з помилками чи некоректно інтерпретувати сучасний CSS.
А от якщо ти поставиш вподобайку цьому допису, то ніякий quirks mode твою верстку не зламає.
Це може призвести до багатьох "цікавих" наслідків, серед яких можлива неправильна обробка семантичних елементів, що може суттєво впливати на доступність, чи застосовуватись якісь CSS-хаки з доісторичних часів, через що непередбачувано попливуть ваші стилі, і ще всілякі інші сюрпризи.
І от саме тому вказувати DOCTYPE в документі зараз важливо, як ніколи, якщо ми хочемо, аби бравзер правильно обробляв його, ми могли використовувати найсучасніші можливості HTML та CSS, і нам не боліла голова через кросбравзерність (вірніше її відсутність). Якщо коротко — DOCTYPE це єдиний спосіб гарантувати, що бравзер працює в сучасному стандартному режимі, а не перетворюється на симулятор Internet Explorer 5.
Спробуйте відкрити свою стару верстку без <!DOCTYPE html> — і розкажіть в коментарях, наскільки все поїхало. Або не поїхало 😉
MDN: Understanding quirks and standards modes
@babichdev
***
Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває, і ми вже перетнули позначку в 50 000 грн! Нагадую, кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
❤71🔥21👏5
#ДонатНаРЕБ
Друзі, ми перетнули позначку в 50 000 гривень в нашому зборі для 109 ОГШБ 10 ОГШБр "Едельвейс", а це значить, що клавіатура R-Go Compact Break від моїх друзів з ERGO PLACE знайшла свого власника!
Тепер останній ривок і фінальна мета в 100 000 гривень, після якої я розіграю 🎁 LEGO Dune Atreides Royal Ornithopter від української продуктової IT-компанії Brainstack!
Нагадую, що кожні 50 гривень вашого донату — це додатковий шанс стати власником цього чудового подарунку!
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
Дякую усім, хто долучається! І памʼятайте — кожна гривня важлива.
Друзі, ми перетнули позначку в 50 000 гривень в нашому зборі для 109 ОГШБ 10 ОГШБр "Едельвейс", а це значить, що клавіатура R-Go Compact Break від моїх друзів з ERGO PLACE знайшла свого власника!
Тепер останній ривок і фінальна мета в 100 000 гривень, після якої я розіграю 🎁 LEGO Dune Atreides Royal Ornithopter від української продуктової IT-компанії Brainstack!
Нагадую, що кожні 50 гривень вашого донату — це додатковий шанс стати власником цього чудового подарунку!
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
Дякую усім, хто долучається! І памʼятайте — кожна гривня важлива.
🔥8❤1
#цього_тижня ми з вами дізналися:
— Що таке Promise.withResolvers та як з ними писати трошечки структурованіший код;
— Якою була моя найперша в карʼєрі задача, і чи завершилася вона успіхом;
— Чому надзвичайно важливо завжди писати DOCTYPE на початку HTML-документів.
***
Також завдяки вашим донати збір для 109 ОГШБ 10 ОГШБр "Едельвейс" перетнув позначку в 50 000 гривень.
Ну я сходив на риболовлю ;)
Гарних вам вихідних, друзі!
@babichweb
.
— Що таке Promise.withResolvers та як з ними писати трошечки структурованіший код;
— Якою була моя найперша в карʼєрі задача, і чи завершилася вона успіхом;
— Чому надзвичайно важливо завжди писати DOCTYPE на початку HTML-документів.
***
Також завдяки вашим донати збір для 109 ОГШБ 10 ОГШБр "Едельвейс" перетнув позначку в 50 000 гривень.
Ну я сходив на риболовлю ;)
Гарних вам вихідних, друзі!
@babichweb
.
❤25🔥5
Львове! Зустрінемось? ;)
Запрошую вас на благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!
Як "забаганка" стейкхолдера перетворюється на чітко поставлену задачу в Jira? Цей процес не такий простий, як здається — і кожен фахівець бачить його по-своєму.
Разом з Kaizen Hub ми запросили Мар'яну Бандровську — ex-Head of BA в Sombra, Романа Марінського — Core Quality CoE expert в Intellias та В'ячеслава Колдовського — Competence Manager в SoftServe, аби обговорити весь шлях від першої ідеї до готового таску. Кожен розповість про свою роль у цьому процесі:
— Як правильно "розпакувати" вимогу та зробити її зрозумілою для всіх
— Що потрібно врахувати для якісного тестування
— Яка технічна інформація критично важлива для реалізації
Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами
Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.
Ну а я цю подію модеруватиму.
Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями
🚀 КВИТКИ ПРИДБАТИ ТУТ
Усі виручені кошти підуть на потреби ЗСУ!
Ну то як, зустрінемось?
Запрошую вас на благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!
Як "забаганка" стейкхолдера перетворюється на чітко поставлену задачу в Jira? Цей процес не такий простий, як здається — і кожен фахівець бачить його по-своєму.
Разом з Kaizen Hub ми запросили Мар'яну Бандровську — ex-Head of BA в Sombra, Романа Марінського — Core Quality CoE expert в Intellias та В'ячеслава Колдовського — Competence Manager в SoftServe, аби обговорити весь шлях від першої ідеї до готового таску. Кожен розповість про свою роль у цьому процесі:
— Як правильно "розпакувати" вимогу та зробити її зрозумілою для всіх
— Що потрібно врахувати для якісного тестування
— Яка технічна інформація критично важлива для реалізації
Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами
Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.
Ну а я цю подію модеруватиму.
Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями
🚀 КВИТКИ ПРИДБАТИ ТУТ
Усі виручені кошти підуть на потреби ЗСУ!
Ну то як, зустрінемось?
❤11🔥3🤔3
Як зупиняти події?
Будь-який розробник рано чи пізно стикається з необхідністю “зловити” подію, виконати якусь свою логіку та зупинити подальшу роботу цієї події.
І річ у тім, що існує два сценарії, в яких подія може продовжитись: це спливання події вгору по DOM та виконання стандартної поведінки елемента.
Найкращий приклад — будь-яка кнопка у формі. Найперша проблема, з якою ми стикнемося, якщо просто навісимо event listener — наш код виконається, але відразу по тому сторінку буде автоматично перезавантажено. Бо така от поведінка у будь-якої кнопки у формі — відправляти дані форми на сервер, незалежно від того, хочемо ми цього чи ні.
Тут у нагоді стане старий добрий метод Event.preventDefault, який каже бравзеру відкинути стандартну поведінку елемента — тобто зупиняє виконання події за замовчуванням.
А якщо у нас із якоїсь причини на вкладених елементах однакові слухачі (наприклад, слухаємо клік на батьківському й дочірньому елементі), то на поміч прийде Event.stopPropagation — метод, який зупиняє просування події вгору по DOM.
До речі, є ще радикальніший спосіб зупинити виконання event listeners — це Event.stopImmediatePropagation, який скасовує виконання наступних слухачів тієї ж події на тому ж елементі.
Знати різницю між цими методами критично важливо, щоби уникнути дивної поведінки у формах, модалках чи складних компонентах. Ну і аби не писати, як я свого часу, коли ніяк не міг запамʼятати, хто з них що робить:
MDN: Event.stopPropagation
MDN: Event.stopImmediatePropagation
MDN: Event.preventDefault
А ви як, досі плутаєтесь в цих методах, як я, чи нарешті запамʼятали різницю? Розкажіть в коментарях!
@babichdev
***
Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває, і ми прямуємо до мети в 100 000 грн! Нагадую, кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
Будь-який розробник рано чи пізно стикається з необхідністю “зловити” подію, виконати якусь свою логіку та зупинити подальшу роботу цієї події.
І річ у тім, що існує два сценарії, в яких подія може продовжитись: це спливання події вгору по DOM та виконання стандартної поведінки елемента.
Найкращий приклад — будь-яка кнопка у формі. Найперша проблема, з якою ми стикнемося, якщо просто навісимо event listener — наш код виконається, але відразу по тому сторінку буде автоматично перезавантажено. Бо така от поведінка у будь-якої кнопки у формі — відправляти дані форми на сервер, незалежно від того, хочемо ми цього чи ні.
Тут у нагоді стане старий добрий метод Event.preventDefault, який каже бравзеру відкинути стандартну поведінку елемента — тобто зупиняє виконання події за замовчуванням.
А якщо у нас із якоїсь причини на вкладених елементах однакові слухачі (наприклад, слухаємо клік на батьківському й дочірньому елементі), то на поміч прийде Event.stopPropagation — метод, який зупиняє просування події вгору по DOM.
До речі, є ще радикальніший спосіб зупинити виконання event listeners — це Event.stopImmediatePropagation, який скасовує виконання наступних слухачів тієї ж події на тому ж елементі.
Знати різницю між цими методами критично важливо, щоби уникнути дивної поведінки у формах, модалках чи складних компонентах. Ну і аби не писати, як я свого часу, коли ніяк не міг запамʼятати, хто з них що робить:
el.addEventListener(event => {
event.stopPropagation();
event.preventDefault();
});MDN: Event.stopPropagation
MDN: Event.stopImmediatePropagation
MDN: Event.preventDefault
А ви як, досі плутаєтесь в цих методах, як я, чи нарешті запамʼятали різницю? Розкажіть в коментарях!
@babichdev
***
Збір на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс» триває, і ми прямуємо до мети в 100 000 грн! Нагадую, кожні 50 грн — шанс виграти подарунок і допомогти ЗСУ.
❤26👏11🔥9
DOU
Зарплатне опитування DOU і портрет айтівця. Долучайтеся!
Запускаємо літнє зарплатне опитування DOU. На анкету знадобиться не більше як 10 хв. Чекаємо всіх айтівців - тих, хто живе в Україні та за кордоном. І спеціалістів усіх напрямів: розробників, QA, менеджерів, DevOps, маркетологів, сапорт, сейлз, HR тощо. Результати…
#партнерський_допис
Що зараз з зарплатами в ІТ?
І хто з айтівців працює на кількох ролях одночасно? Скільки людей залишаються в Україні, а скільки планують виїхати? Чи дає профільна освіта перевагу?
DOU запустили літнє зарплатне опитування, щоб зробити аналітику зарплат і портрет айтівця 2025. Час на заповнення — до 10 хвилин, тож приділіть трошки часу, будь ласка ;)
Можна заповнювати незалежно від того, де ви зараз — в Україні чи за кордоном, працюєте в ІТ-компанії чи в ІТ-відділі банку. У списку 300 посад і 160 спеціалізацій — знайдеться кожен.
👉 https://dou.ua/goto/ikMs
Що зараз з зарплатами в ІТ?
І хто з айтівців працює на кількох ролях одночасно? Скільки людей залишаються в Україні, а скільки планують виїхати? Чи дає профільна освіта перевагу?
DOU запустили літнє зарплатне опитування, щоб зробити аналітику зарплат і портрет айтівця 2025. Час на заповнення — до 10 хвилин, тож приділіть трошки часу, будь ласка ;)
Можна заповнювати незалежно від того, де ви зараз — в Україні чи за кордоном, працюєте в ІТ-компанії чи в ІТ-відділі банку. У списку 300 посад і 160 спеціалізацій — знайдеться кожен.
👉 https://dou.ua/goto/ikMs
🔥8❤4
Вісімнадцять років тому, 11 червня 2007 року, сталася цікава подія, що вплинула як не на розвиток веброзробки в цілому, то на моє цинічне до неї ставлення так точно.
Apple випустила Safari для Windows.
Це була спроба конкуренції з Internet Explorer і Firefox, з обіцянками “найшвидшого браузера на планеті”. Версія для Windows вийшла одразу як бета, проте мала багато багів та обмежену підтримку вебстандартів, і взагалі відчувалась як "інородне тіло" в системі Windows.
Попри кілька років підтримки, Safari for Windows помер тихо уві сні у 2012 році. Apple припинила оновлення без офіційного анонсу — дистрибутив просто зник з сайту.
Що цікаво, Internet Explorer свого часу теж був представлений в екосистемі Mac, ще з 1996 року. Так-так, з версії IE 2.0! І "каденція" бравзера від Microsoft на системі конкурентів тривала дещо довше — у 2003 році було припинено розвиток цієї версії, а остаточно підтримку життєдіяльности відключили аж 2005 року.
А тепер хочете прикол? IE був браузером за замовчанням на Mac OS 8 та Mac OS 9, і навіть ранні версії Mac OS X. Найперша версія Safari просто зʼявилася лише 2003 року.
Отак ми й жили у 2000-х: спочатку Microsoft пхав Internet Explorer у macOS, потім Apple пхала Safari у Windows, а веброзробники пхали тонни CSS-хаків, щоб хоч якось усе виглядало однаково. І усе це на тлі Помаранчевої революції, світової фінансової кризи та першого сезону "Сімпсонів" українською.
Минуло 18 років, браузерні війни давно відшуміли, стандарти перемогли. Але я досі не можу пробачити Safari for Windows за його рендерінг шрифтів.
@babichdev
P.S. Сьогодні ЗСУ перетнули позначку в 1 000 000 дохлих та покалічених кацапів, то чого б і нам не перетнути позначку в 100 000 гривень у нашому зборі на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс»?
Apple випустила Safari для Windows.
Це була спроба конкуренції з Internet Explorer і Firefox, з обіцянками “найшвидшого браузера на планеті”. Версія для Windows вийшла одразу як бета, проте мала багато багів та обмежену підтримку вебстандартів, і взагалі відчувалась як "інородне тіло" в системі Windows.
Попри кілька років підтримки, Safari for Windows помер тихо уві сні у 2012 році. Apple припинила оновлення без офіційного анонсу — дистрибутив просто зник з сайту.
Що цікаво, Internet Explorer свого часу теж був представлений в екосистемі Mac, ще з 1996 року. Так-так, з версії IE 2.0! І "каденція" бравзера від Microsoft на системі конкурентів тривала дещо довше — у 2003 році було припинено розвиток цієї версії, а остаточно підтримку життєдіяльности відключили аж 2005 року.
А тепер хочете прикол? IE був браузером за замовчанням на Mac OS 8 та Mac OS 9, і навіть ранні версії Mac OS X. Найперша версія Safari просто зʼявилася лише 2003 року.
Отак ми й жили у 2000-х: спочатку Microsoft пхав Internet Explorer у macOS, потім Apple пхала Safari у Windows, а веброзробники пхали тонни CSS-хаків, щоб хоч якось усе виглядало однаково. І усе це на тлі Помаранчевої революції, світової фінансової кризи та першого сезону "Сімпсонів" українською.
Минуло 18 років, браузерні війни давно відшуміли, стандарти перемогли. Але я досі не можу пробачити Safari for Windows за його рендерінг шрифтів.
@babichdev
P.S. Сьогодні ЗСУ перетнули позначку в 1 000 000 дохлих та покалічених кацапів, то чого б і нам не перетнути позначку в 100 000 гривень у нашому зборі на РЕБ для 109 ОГШБ 10 ОГШБр «Едельвейс»?
🔥52❤19
Щось ви останнім часом рідше ділитеся зі мною серденьками й вогниками. Може, теми втомили? Може, увага на іншому? А може, я вже не той (ага, за півтора місяці)?
Допоможіть мені знову збирати всі вподобайки світу — підкажіть, про що хочете читати далі?
Допоможіть мені знову збирати всі вподобайки світу — підкажіть, про що хочете читати далі?
Anonymous Poll
53%
Технічні нюанси (DOM, CSS, HTML, API)
68%
Архітектура, фреймворки, патерни
36%
Карʼєра, співбесіди, шлях самурая
31%
Особисті спостереження, роздуми
2%
Інше (напишіть у коментарях)
🔥59❤12🤔5👏2
Масштабуйся як Чак Норіс
Спочатку усе просто — маленький компонент, зрозумілий, логічний, швидкий. Але з часом, непомітно, маленькими кроками, він починає перетворюватись на монстра Франкенштейна: спочатку це прапорці isMobile чи isAdmin, згодом цілі шматки розмітки чи логіки та десяток колбеків на всі випадки життя. І ось в результаті перед вами дещо, в хитросплетіннях умовних конструкцій якого уже ніхто не розбереться без архітектора.
Знайомо? Та знайомо, не прикидайтесь. Усі ми проходили через це — швиденько докинути іфку, потім нормально зроблю ж. І от маємо внаслідокБога-Імператора god component, який намагається робити все.
З часом складність та заплутаність лише зростатимуть. І що ж з цим робити?
Розділяйте та володарюйте
Single Responsibility ще ніхто не скасовував. Головне не плутати відповідальність з функціональністю. Це трохи різні речі. Розділяйте, виносьте, інкапсулюйте. Чим чіткіше окреслена відповідальність компонента системи, тим легше з ним працювати, очевидно.
Мисліть сценаріями, а не прапорцями
Кількість можливих комбінацій прапорців зростатиме експоненційно, і настане момент, коли ви просто в них захлинетесь. Якщо всередині компонента усе ж треба різна поведінка в залежності від параметрів, краще визначити стійкі сценарії, комбінації цих параметрів, замість спроб рахувати все всередині.
Логіка компонента — за межами компонента
Складна внутрішня поведінка має право бути. Різні обчислення, композиція даних з різних джерел, умовна логіка — це не зло. Але це все має бути контрольованим, а головне — не змішуватись із представленням. Якщо ваш компонент має лише одне джерело стану, його набагато легше тестувати, а відповідну логіку — оптимізувати і рефакторити.
Ваш компонент — не швейцарський ніж
Якщо він робить усе — він не робить добре нічого. Чим складніша система, тим вірогідніша її відмова. Композиція завжди краща за універсальність. Замість розширювати — розділяйте, замість ускладнювати один компонент — компонуйте з кількох дрібних.
***
Звичайно, сидіти квочкою над кожним рядком коду вам ніхто не каже. То як розпізнати дзвіночки, що компонент починає набирати зайву вагу?
Стає складніше тестувати
В ідеалі ви маєте тестувати компонент на основні простих сценаріїв: успіх, помилка, невизначений стан (завантаження, наприклад). Якщо ви вже починаєте плодити кейси на третій чи пʼятий набір умов — пора задумуватись.
Нова вимога — нова умова
if у такому випадку — ваш найгірший друг. Ніби й може виручити, але це потім вилізе боком. Особисто мені здається, що умовна логіка повинна впливати виключно на композицію, а не складність компонента.
Неможливо описати компонент одним реченням
"Що воно робить?". Якщо ваш компонент це виробництво повного циклу, половину якого ви не розумієте, вітаю — у вас проблеми.
Існує "Режим Х"
В якому компонент поводиться і виглядає на 100% інакше, аніж за замовчуванням. Поведінка має варіюватися, але в жодному разі не відрізнятися кардинально.
***
Ці всі поради не про містичну "чистоту коду", вони про контроль над змінами, над логікою, про те, куди рухаються ваші компоненти, і скільки буде вартувати один прапорець в майбутньому.
Код може бути складним, але у жодному разі не має бути заплутаним.
@babichdev
—
Ну шо, за таке наголосували, чи ні? Чекаю на ваші вподобайки та палку дискусію в коментарях!
Крім вогника можете ще й 50 гривень на збір закинуть.
Спочатку усе просто — маленький компонент, зрозумілий, логічний, швидкий. Але з часом, непомітно, маленькими кроками, він починає перетворюватись на монстра Франкенштейна: спочатку це прапорці isMobile чи isAdmin, згодом цілі шматки розмітки чи логіки та десяток колбеків на всі випадки життя. І ось в результаті перед вами дещо, в хитросплетіннях умовних конструкцій якого уже ніхто не розбереться без архітектора.
Знайомо? Та знайомо, не прикидайтесь. Усі ми проходили через це — швиденько докинути іфку, потім нормально зроблю ж. І от маємо внаслідок
З часом складність та заплутаність лише зростатимуть. І що ж з цим робити?
Розділяйте та володарюйте
Single Responsibility ще ніхто не скасовував. Головне не плутати відповідальність з функціональністю. Це трохи різні речі. Розділяйте, виносьте, інкапсулюйте. Чим чіткіше окреслена відповідальність компонента системи, тим легше з ним працювати, очевидно.
Мисліть сценаріями, а не прапорцями
Кількість можливих комбінацій прапорців зростатиме експоненційно, і настане момент, коли ви просто в них захлинетесь. Якщо всередині компонента усе ж треба різна поведінка в залежності від параметрів, краще визначити стійкі сценарії, комбінації цих параметрів, замість спроб рахувати все всередині.
Логіка компонента — за межами компонента
Складна внутрішня поведінка має право бути. Різні обчислення, композиція даних з різних джерел, умовна логіка — це не зло. Але це все має бути контрольованим, а головне — не змішуватись із представленням. Якщо ваш компонент має лише одне джерело стану, його набагато легше тестувати, а відповідну логіку — оптимізувати і рефакторити.
Ваш компонент — не швейцарський ніж
Якщо він робить усе — він не робить добре нічого. Чим складніша система, тим вірогідніша її відмова. Композиція завжди краща за універсальність. Замість розширювати — розділяйте, замість ускладнювати один компонент — компонуйте з кількох дрібних.
***
Звичайно, сидіти квочкою над кожним рядком коду вам ніхто не каже. То як розпізнати дзвіночки, що компонент починає набирати зайву вагу?
Стає складніше тестувати
В ідеалі ви маєте тестувати компонент на основні простих сценаріїв: успіх, помилка, невизначений стан (завантаження, наприклад). Якщо ви вже починаєте плодити кейси на третій чи пʼятий набір умов — пора задумуватись.
Нова вимога — нова умова
if у такому випадку — ваш найгірший друг. Ніби й може виручити, але це потім вилізе боком. Особисто мені здається, що умовна логіка повинна впливати виключно на композицію, а не складність компонента.
Неможливо описати компонент одним реченням
"Що воно робить?". Якщо ваш компонент це виробництво повного циклу, половину якого ви не розумієте, вітаю — у вас проблеми.
Існує "Режим Х"
В якому компонент поводиться і виглядає на 100% інакше, аніж за замовчуванням. Поведінка має варіюватися, але в жодному разі не відрізнятися кардинально.
***
Ці всі поради не про містичну "чистоту коду", вони про контроль над змінами, над логікою, про те, куди рухаються ваші компоненти, і скільки буде вартувати один прапорець в майбутньому.
Код може бути складним, але у жодному разі не має бути заплутаним.
@babichdev
—
Ну шо, за таке наголосували, чи ні? Чекаю на ваші вподобайки та палку дискусію в коментарях!
Крім вогника можете ще й 50 гривень на збір закинуть.
🔥84❤15👏1