#ДонатНаРЕБ
Друзі, ми перетнули позначку в 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
Пані та панове, нагадую, що вже завтра у Львові відбудеться благодійний мітап "Від ʼхотілкиʼ до задачі: звідки беруться таски у вашій джирі"!
Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами
Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.
Ну а я цю подію модеруватиму.
Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями
🚀 КВИТКИ ПРИДБАТИ ТУТ
Усі виручені кошти підуть на потреби ЗСУ!
Обговоримо типові проблеми на кожному етапі трансформації вимог:
— Як різні ролі бачать одну й ту саму задачу
— Які питання треба ставити, щоб уникнути недопорозумінь
— Практичні інструменти для ефективної комунікації між командами
Після дискусії — сесія Q&A, де ви зможете поставити свої запитання панелістам та отримати поради для конкретних ситуацій.
Ну а я цю подію модеруватиму.
Коли: 14 червня, 13:00
Де: Гастропаб "Довгі бурхливі оплески", Львів, вул. Січових Стрільців 3
Вартість: благодійний внесок 500 грн
Для кого: BA, PM, QA, розробники, тімліди — всі, хто працює з вимогами та управлінням завданнями
🚀 КВИТКИ ПРИДБАТИ ТУТ
Усі виручені кошти підуть на потреби ЗСУ!
❤7🔥5
Дивовижний світ веброзробки
Масштабуйся як Чак Норіс Спочатку усе просто — маленький компонент, зрозумілий, логічний, швидкий. Але з часом, непомітно, маленькими кроками, він починає перетворюватись на монстра Франкенштейна: спочатку це прапорці isMobile чи isAdmin, згодом цілі шматки…
#цього_тижня ми дізналися:
— Як зупиняти DOM-події
— Що Safari виходило під вінду
— Як масштабувати компоненти як Чак Норіс
А зараз — час відпочити та подивитися улюблений серіал чи почитати цікаву книжку. Відкладіть все до понеділка, робота нікуди не дінеться ;)
— Як зупиняти DOM-події
— Що Safari виходило під вінду
— Як масштабувати компоненти як Чак Норіс
А зараз — час відпочити та подивитися улюблений серіал чи почитати цікаву книжку. Відкладіть все до понеділка, робота нікуди не дінеться ;)
❤28👏1
Шлях від .html до пікселів на екрані
…довгий, тернистий та заплутаний. Сьогодні хочу оглянути те, як бравзер перетворює текст в html-файлі на зображення у вікні перегляду. Але заглиблюватись не буду, бо навіть у форматі півторагодинної лекції мені не вдавалось охопити усю глибину.
Починається усе з того, що ще під час завантаження файлу бравзер уже на льоту намагається зібрати DOM. Для цього йому достатньо знайти в текстовому потоці токен: відкриваючий чи закриваючий тег, текстову послідовність чи коментар. Щойно токен знайдено, він відразу передається до tree builder, що створює DOM-вузол в DOM-дереві. І ось такою чехардою, крок за кроком, бравзер створює те саме DOM-дерево: токен-вузол-токен-вузол….
Це може відбуватися плавно й безперервно, а може перериватися, якщо бравзер натикається на вставлений або підключений скрипт. В такому випадку парсинг та побудова DOM відкладаються до кращих часів (хоча зараз для оптимізації парсинг може продовжуватися на тлі, але результат викидається на смітник в разі чого), бо бравзер очікує, що скрипт може змінити структуру документа.
Якщо ж бравзер знаходить стилі, то парсинг не припиняється, але може заблокувати безпосередній рендер, себто відмальовку. Чому — трошки далі. Усі стилі також паралельно собі парсяться і з них складається окреме дерево — CSSOM.
І от коли бравзер має на рукахусі козирі обидва дерева, DOM та CSSOM, він з них складає третє — render tree. Його призначення — бути інструкцією до збірки фінального зображення, тому той же display: none не включається до render tree.
Тому будь-яка зміна в DOM чи CSS призводять до перерахунку цього render-tree. Майте на увазі.
Наступний крок, після того, як весь дендропарк зібрано докупи — розрахунок layout, або ж блочного макету. На цьому етапі бравзер, беручи за основу render-tree, розраховує, як саме розташовані блоки відносно один одного. Саме на цьому етапі враховуються розміри елементів, відступи, бордери та інші "фізичні" метрики.
Зазвичай бравзер намагається завершити це в один прохід, користуючись "потоковою моделллю", вважаючи, що елементи "плинуть" зліва направо та зверху вниз. Однак, якщо ви використали таблички або CSS-grid, бравзеру доведеться цей процес повторити далеко не один раз.
Після того, як він нарешті обробиться усі ваші хитромудрі лейаути, і блочний макет буде збудовано, бравзер нарешті зможе зайнятися антистрес-розмальовками, тобто збирати все докупи в одне зображення на етапі paint. Тут він буде вже застосовувати і шрифти, і кольори, і картинки ваші, і склеювати усі шари, які ви постворювали своїми position: absolute чи трансформами.
І аж по тому, як він все "запече" в одне зображення, бравзер виведе його у вʼюпорт, тобто у область відображення.
Звичайно ж, я надзвичайно спростив усе, і не розповів про ту неймовірну купу оптимізацій, до яких вдаються сучасні бравзери. Але для загального розуміння нам вистачить, я сподіваюсь.
А як хочете глибшого огляду — дайте знати в коментарях. Ну і вогників насипте вже, вам не складно, мені приємно.
@babichdev
…довгий, тернистий та заплутаний. Сьогодні хочу оглянути те, як бравзер перетворює текст в html-файлі на зображення у вікні перегляду. Але заглиблюватись не буду, бо навіть у форматі півторагодинної лекції мені не вдавалось охопити усю глибину.
Починається усе з того, що ще під час завантаження файлу бравзер уже на льоту намагається зібрати DOM. Для цього йому достатньо знайти в текстовому потоці токен: відкриваючий чи закриваючий тег, текстову послідовність чи коментар. Щойно токен знайдено, він відразу передається до tree builder, що створює DOM-вузол в DOM-дереві. І ось такою чехардою, крок за кроком, бравзер створює те саме DOM-дерево: токен-вузол-токен-вузол….
Це може відбуватися плавно й безперервно, а може перериватися, якщо бравзер натикається на вставлений або підключений скрипт. В такому випадку парсинг та побудова DOM відкладаються до кращих часів (хоча зараз для оптимізації парсинг може продовжуватися на тлі, але результат викидається на смітник в разі чого), бо бравзер очікує, що скрипт може змінити структуру документа.
Якщо ж бравзер знаходить стилі, то парсинг не припиняється, але може заблокувати безпосередній рендер, себто відмальовку. Чому — трошки далі. Усі стилі також паралельно собі парсяться і з них складається окреме дерево — CSSOM.
І от коли бравзер має на руках
Тому будь-яка зміна в DOM чи CSS призводять до перерахунку цього render-tree. Майте на увазі.
Наступний крок, після того, як весь дендропарк зібрано докупи — розрахунок layout, або ж блочного макету. На цьому етапі бравзер, беручи за основу render-tree, розраховує, як саме розташовані блоки відносно один одного. Саме на цьому етапі враховуються розміри елементів, відступи, бордери та інші "фізичні" метрики.
Зазвичай бравзер намагається завершити це в один прохід, користуючись "потоковою моделллю", вважаючи, що елементи "плинуть" зліва направо та зверху вниз. Однак, якщо ви використали таблички або CSS-grid, бравзеру доведеться цей процес повторити далеко не один раз.
Після того, як він нарешті обробиться усі ваші хитромудрі лейаути, і блочний макет буде збудовано, бравзер нарешті зможе зайнятися антистрес-розмальовками, тобто збирати все докупи в одне зображення на етапі paint. Тут він буде вже застосовувати і шрифти, і кольори, і картинки ваші, і склеювати усі шари, які ви постворювали своїми position: absolute чи трансформами.
І аж по тому, як він все "запече" в одне зображення, бравзер виведе його у вʼюпорт, тобто у область відображення.
Якщо допис був корисним — можна подякувати донатом на збір на РЕБ для 109 ОГШБ 10 ОГШБр "Едельвейс"
Усього 50 грн — але це реальна користь для фронту.
Звичайно ж, я надзвичайно спростив усе, і не розповів про ту неймовірну купу оптимізацій, до яких вдаються сучасні бравзери. Але для загального розуміння нам вистачить, я сподіваюсь.
А як хочете глибшого огляду — дайте знати в коментарях. Ну і вогників насипте вже, вам не складно, мені приємно.
@babichdev
🔥112❤9👏2
Пані та панове, хоч на сьогодні заплановані й інші дописи, але просто зараз мушу нагадати про наш збір на РЕБ для 109 ОГШБ 10 ОГШБр "Едельвейс".
Нам лишається навіть менше, аніж 40 000 гривень до мети.
Від нашої з вами допомоги залежить дуже багато.
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
І просто як нагадування: Росія — це кончена країна кончених людей. А ми мусимо встояти, бо іншого шляху немає.
Нам лишається навіть менше, аніж 40 000 гривень до мети.
Від нашої з вами допомоги залежить дуже багато.
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
І просто як нагадування: Росія — це кончена країна кончених людей. А ми мусимо встояти, бо іншого шляху немає.
❤23
#анонс
У 2023 році Альберт Пивненко став другим учасником технічних співбесід у мене на каналі. Після етеру — отримав офер. Після оферу — почав нове життя в розробці.
Колись він був вчителем. Потім — охоронцем. А сьогодні він — фронтенд-інженер.
Етер два роки тому виявився для нього точкою входу. Цей же стане перевіркою.
І на нього чекатимуть не лише цікаві питання, а й складні завдання та нові виклики.
Усе як ви любите: наживо, без монтажу, без сценарію.
І без поблажок.
🗓 20 червня | 19:00
📍 YouTube канал Сергій Бабіч та Дивовижний світ веброзробки
🔗 ПОСИЛАННЯ НА ЕТЕР
Не забудьте підписатися і поставити дзвіночок. Чекатиму на вас у пʼятницю!
@babichdev
У 2023 році Альберт Пивненко став другим учасником технічних співбесід у мене на каналі. Після етеру — отримав офер. Після оферу — почав нове життя в розробці.
Колись він був вчителем. Потім — охоронцем. А сьогодні він — фронтенд-інженер.
Етер два роки тому виявився для нього точкою входу. Цей же стане перевіркою.
І на нього чекатимуть не лише цікаві питання, а й складні завдання та нові виклики.
Усе як ви любите: наживо, без монтажу, без сценарію.
І без поблажок.
🗓 20 червня | 19:00
📍 YouTube канал Сергій Бабіч та Дивовижний світ веброзробки
Не забудьте підписатися і поставити дзвіночок. Чекатиму на вас у пʼятницю!
@babichdev
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥44❤8
#про_співбесіди
У вас пʼять років досвіду, ви переписали десятки компонентів (і двічі — один і той самий), але досі не знаєте, чи вже синьйор? Ось запитання, яке я ставлю кожному кандидату — і воно швидко розкладає все по місцях.
Це запитання — один з найсильніших індикаторів для мене: чи готова людина до синьйорної ролі. Яким чином? Дуже просто — за рахунок глибини відповіді.
Якщо ви почнете розповідати деталі імплементації, що саме було зроблено, які бібліотеки використали чи патерни застосували, але при цьому не розкриєте вплив, який ці рішення мали на продукт, кодову базу чи процес розробки — що ж, на жаль (на мою особисту думку), ви ще не готові.
Чому? Бо синьйор має в першу чергу мислити стратегічно, зважувати плюси й мінуси рішень, передбачати цей самий вплив, а вже потім думати про конкретні кроки імплементації. Я не кажу зараз про те саме затаскане "продуктове мислення", хоча воно тут теж має значення. Мова йде про розуміння в цілому, широке бачення, усвідомлення довгострокового впливу.
Щоб відповісти на такі питання, треба мати досвід "кроку назад", коли ви оцінюєте не тільки наслідки тут і зараз, а прикидаєте, що саме це дасть: прискорення розробки, підтримуваність коду, легкість внесення змін, покращення швидкодії і так далі. Це цілком може бути частиною досвіду й мідл-інженера.
Для цього, стаючи до роботи над подібними змінами, треба питати себе не лише "як це зробити", а й "що це нам дасть". Не соромтесь діставати цими питаннями ваших синьйорів, лідів, продактів та інших дотичних до рішення людей. Тоді ви навчитеся оцінювати ініціативи не лише суто з практичної точки зору, а й почнете потроху розуміти довгостроковий вплив.
А коли ви його зрозумієте, то до прийняття багатьох рішень ви будете підходити геть з іншого боку, і навчитеся відкидати такі, що здаються вигідними тут і зараз. Бо горизонт планування й оцінювання розшириться далі одного спринта.
А це і є, на мою особисту думку, однією з важливих якостей дійсно синьйорного інженера, бо у завтрашній день можуть дивитися не тільки лиш усі.
Тому, готуючись до співбесіди, підготуйтесь до цього питання, згадайте, коли ви пропонували велику технічну зміну і спробуйте пояснити самі собі, які наслідки вона мала, згадайте, як вона вплинула на процес розробки й ефективність команди.
@babichdev
У вас пʼять років досвіду, ви переписали десятки компонентів (і двічі — один і той самий), але досі не знаєте, чи вже синьйор? Ось запитання, яке я ставлю кожному кандидату — і воно швидко розкладає все по місцях.
Чи брав кандидат участь в якійсь значній технічній ініціативі: чи як ключовий учасник, чи ініціатор?
Це запитання — один з найсильніших індикаторів для мене: чи готова людина до синьйорної ролі. Яким чином? Дуже просто — за рахунок глибини відповіді.
Якщо ви почнете розповідати деталі імплементації, що саме було зроблено, які бібліотеки використали чи патерни застосували, але при цьому не розкриєте вплив, який ці рішення мали на продукт, кодову базу чи процес розробки — що ж, на жаль (на мою особисту думку), ви ще не готові.
Чому? Бо синьйор має в першу чергу мислити стратегічно, зважувати плюси й мінуси рішень, передбачати цей самий вплив, а вже потім думати про конкретні кроки імплементації. Я не кажу зараз про те саме затаскане "продуктове мислення", хоча воно тут теж має значення. Мова йде про розуміння в цілому, широке бачення, усвідомлення довгострокового впливу.
Щоб відповісти на такі питання, треба мати досвід "кроку назад", коли ви оцінюєте не тільки наслідки тут і зараз, а прикидаєте, що саме це дасть: прискорення розробки, підтримуваність коду, легкість внесення змін, покращення швидкодії і так далі. Це цілком може бути частиною досвіду й мідл-інженера.
Для цього, стаючи до роботи над подібними змінами, треба питати себе не лише "як це зробити", а й "що це нам дасть". Не соромтесь діставати цими питаннями ваших синьйорів, лідів, продактів та інших дотичних до рішення людей. Тоді ви навчитеся оцінювати ініціативи не лише суто з практичної точки зору, а й почнете потроху розуміти довгостроковий вплив.
А коли ви його зрозумієте, то до прийняття багатьох рішень ви будете підходити геть з іншого боку, і навчитеся відкидати такі, що здаються вигідними тут і зараз. Бо горизонт планування й оцінювання розшириться далі одного спринта.
А це і є, на мою особисту думку, однією з важливих якостей дійсно синьйорного інженера, бо у завтрашній день можуть дивитися не тільки лиш усі.
Тому, готуючись до співбесіди, підготуйтесь до цього питання, згадайте, коли ви пропонували велику технічну зміну і спробуйте пояснити самі собі, які наслідки вона мала, згадайте, як вона вплинула на процес розробки й ефективність команди.
@babichdev
🔥44❤8🤔1
#про_співбесіди
Просто зараз я готуюсь до вечірнього етеру зі співбесідою — підбираю теми, завдання, придумую хитрі задачки. І на думку спало швиденько поділитися з вами моєю точкою зору щодо того, як проводити співбесіди з лайвкодингом.
Саме не проходити, а проводити. Бо в цьому випадку відповідальність за вдале проходження такої сесії лежить саме на інтервʼюєрі. Чому?
Бо це дуже стресово. Навіть я не завжди блискуче справляюсь з таким завданнями з дуже простої причини: одна справа розповідати теорію чи ділитися досвідом, і зовсім інша — перемикнутись на "розробницький режим", коли дедлайн не за два тижні, а за 20 хвилин. І при цьому треба ще й коментувати усе, що ти робиш.
Так от. Найперше і найголовніше — підготуйте нескладну і очевидну задачу. Наприклад, якщо це вправа з код-ревʼю, то хай там буде дві-три, максимум пʼять суперочевидних проблем. Не варто перетворювати сесію на квест-кімнату, де помилка криється в сімнадцятій ітерації квантового алгоритма Безоса–Мікі-Мауса.
Не змушуйте мене кожному з вас писати в особисті, щоб ви поставили вподобайку і поширили цей допис
Не перебивайте. Ви можете зупинити кандидата, коли чуєте, що він у своїх роздумах уже мандрує степами Монголії. Але якщо він просто дещо по іншому висловлює свої думки — стуліть писка ненадовго. Нагадати про свою присутність можна, коли запала незручна тиша — тоді можна запропонувати підказку чи допомогу.
Не перетворюйте практичні задачі на театр одного актора у вакуумі, в якому він змушений котити свій камінь на гору в повній тиші, поки ви витріщаєтесь на нього, як Віго Карпатський зі свого портрета. Дозволяйте гуглити, питати у чата, користуватися тим же Cursor чи Copilot, питати поради у вас, врешті-решт. Неважливо, як саме зʼявився код, головне аби кандидат його розумів і міг пояснити.
І не змушуйте учасника співбесіди обовʼязково написати повністю робочий код в установлений час. Це додасть ще більще стресу, і можна взагалі зловити тупняк. Ваша задача — побачити, як кандидат мислить, як працює над рішенням, як він розбирається з вимогами і таке інше. В наш час власне сам код уже не є самоціллю, набагато важливіше, як саме до нього прийшли.
Якщо коротко — не будьте душними, будьте привітними та відкритими, і все складеться добре, як для кандидата, так і для вас.
До речі, нагадую, що сьогодні ввечері — новий прямий етер зі співбесідою на моєму ютуб-каналі, і закликаю вас усіх прийти подивитися саме стрим, а не запис. Буде дуже цікаво, це я вам обіцяю. Чекаю на усіх вас!
Заразом подивитеся, як я ігнорую власні поради, бгг.
@babichdev
Просто зараз я готуюсь до вечірнього етеру зі співбесідою — підбираю теми, завдання, придумую хитрі задачки. І на думку спало швиденько поділитися з вами моєю точкою зору щодо того, як проводити співбесіди з лайвкодингом.
Саме не проходити, а проводити. Бо в цьому випадку відповідальність за вдале проходження такої сесії лежить саме на інтервʼюєрі. Чому?
Бо це дуже стресово. Навіть я не завжди блискуче справляюсь з таким завданнями з дуже простої причини: одна справа розповідати теорію чи ділитися досвідом, і зовсім інша — перемикнутись на "розробницький режим", коли дедлайн не за два тижні, а за 20 хвилин. І при цьому треба ще й коментувати усе, що ти робиш.
Так от. Найперше і найголовніше — підготуйте нескладну і очевидну задачу. Наприклад, якщо це вправа з код-ревʼю, то хай там буде дві-три, максимум пʼять суперочевидних проблем. Не варто перетворювати сесію на квест-кімнату, де помилка криється в сімнадцятій ітерації квантового алгоритма Безоса–Мікі-Мауса.
Не перебивайте. Ви можете зупинити кандидата, коли чуєте, що він у своїх роздумах уже мандрує степами Монголії. Але якщо він просто дещо по іншому висловлює свої думки — стуліть писка ненадовго. Нагадати про свою присутність можна, коли запала незручна тиша — тоді можна запропонувати підказку чи допомогу.
Не перетворюйте практичні задачі на театр одного актора у вакуумі, в якому він змушений котити свій камінь на гору в повній тиші, поки ви витріщаєтесь на нього, як Віго Карпатський зі свого портрета. Дозволяйте гуглити, питати у чата, користуватися тим же Cursor чи Copilot, питати поради у вас, врешті-решт. Неважливо, як саме зʼявився код, головне аби кандидат його розумів і міг пояснити.
І не змушуйте учасника співбесіди обовʼязково написати повністю робочий код в установлений час. Це додасть ще більще стресу, і можна взагалі зловити тупняк. Ваша задача — побачити, як кандидат мислить, як працює над рішенням, як він розбирається з вимогами і таке інше. В наш час власне сам код уже не є самоціллю, набагато важливіше, як саме до нього прийшли.
Якщо коротко — не будьте душними, будьте привітними та відкритими, і все складеться добре, як для кандидата, так і для вас.
До речі, нагадую, що сьогодні ввечері — новий прямий етер зі співбесідою на моєму ютуб-каналі, і закликаю вас усіх прийти подивитися саме стрим, а не запис. Буде дуже цікаво, це я вам обіцяю. Чекаю на усіх вас!
Заразом подивитеся, як я ігнорую власні поради, бгг.
@babichdev
❤96🔥25🤔2
До початку — рівно п'ять хвилин!
Мерщій заварюйте чай і готуйте смаколики, бо рівно о 19:00 розпочнеться прямий етер з новою співбесідою на моєму ютуб каналі!
https://youtube.com/live/bCqM9T3AbFQ
Мерщій заварюйте чай і готуйте смаколики, бо рівно о 19:00 розпочнеться прямий етер з новою співбесідою на моєму ютуб каналі!
https://youtube.com/live/bCqM9T3AbFQ
YouTube
ReactJS | Співбесіда наживо
Питання від партнера: https://forms.gle/78zzibdRaX12PCyL8
У 2023 році Альберт Пивненко став другим учасником технічних співбесід у мене на каналі. Після етеру — отримав офер. Після оферу — почав нове життя в розробці.
Колись він був вчителем. Потім — охоронцем.…
У 2023 році Альберт Пивненко став другим учасником технічних співбесід у мене на каналі. Після етеру — отримав офер. Після оферу — почав нове життя в розробці.
Колись він був вчителем. Потім — охоронцем.…
🔥23
Всім привіт! Мені здається, прийшов час нам познайомитися дещо глибше.
Мене звати Сергій Бабіч, і я веброзробник.
У розробці я вже понад 14 років. За цей час працював в багатьох компаніях і на дуже різних проєктах, з різними технологіями та дуже різними людьми.
Протягом карʼєри я здобув стільки знань і досвіду, що їх стало просто неможливо утримувати в собі, тому я врешті-решт і вирішив започаткувати цей канал. Не блоґ, не інфопомийку з перепостами з інфопомийок, як ви вже помітили, а таке місце сили, через яке я можу ділитися з вами своїми знаннями, своїм досвідом, роздумами та точками зору.
Але не все тут — з мого 14-річного досвіду. Часом спеціально занурююсь у нову тему — і виходжу з неї з відкриттями, якими й ділюсь із вами.
В цьому каналі я пишу про все, що вважаю за дійсно важливе для вас: веброзробку, проведення й проходження співбесід, архітектуру, досвід з проєктів, анонси моїх і не тільки подій, та обовʼязково — про допомогу ЗСУ. І так буде й надалі.
“Але ж ти постиш і рекламу!” — скажете ви. І будете праві. Я справді публікую партнерські дописи. Але тільки ті, що мають сенс саме для вас. І відбираю я кожне оголошення вручну, зважайте.
А ще:
— Моя улюблена частина Assassin's Creed це Black Flag.
— Я з Житомира.
— На українську перейшов сам у віці 18 років далекого 2005 року. Тому не вірю в "не такі щелепи" і "мнє сложна, я живу в [рандомне_місто]". Дивіться пункт 2 ;)
— Обожнюю риболовлю.
А тепер — ваша черга, розкажіть трохи про себе в коментарях: хто ви, звідки, чому підписалися і чи любите робити свою роботу так само, як це люблю я.
А підтримати "Дивовижний світ веброзробки" можна наступним чином:
— Заохотити підписатися хоча б одного колегу, який в житті про мене не чув;
— Ставити на кожен допис як не вогник, то хоча б серденько;
— Стати патроном на BASE від monobank.
@babichdev
Мене звати Сергій Бабіч, і я веброзробник.
У розробці я вже понад 14 років. За цей час працював в багатьох компаніях і на дуже різних проєктах, з різними технологіями та дуже різними людьми.
Протягом карʼєри я здобув стільки знань і досвіду, що їх стало просто неможливо утримувати в собі, тому я врешті-решт і вирішив започаткувати цей канал. Не блоґ, не інфопомийку з перепостами з інфопомийок, як ви вже помітили, а таке місце сили, через яке я можу ділитися з вами своїми знаннями, своїм досвідом, роздумами та точками зору.
Але не все тут — з мого 14-річного досвіду. Часом спеціально занурююсь у нову тему — і виходжу з неї з відкриттями, якими й ділюсь із вами.
В цьому каналі я пишу про все, що вважаю за дійсно важливе для вас: веброзробку, проведення й проходження співбесід, архітектуру, досвід з проєктів, анонси моїх і не тільки подій, та обовʼязково — про допомогу ЗСУ. І так буде й надалі.
“Але ж ти постиш і рекламу!” — скажете ви. І будете праві. Я справді публікую партнерські дописи. Але тільки ті, що мають сенс саме для вас. І відбираю я кожне оголошення вручну, зважайте.
А ще:
— Моя улюблена частина Assassin's Creed це Black Flag.
— Я з Житомира.
— На українську перейшов сам у віці 18 років далекого 2005 року. Тому не вірю в "не такі щелепи" і "мнє сложна, я живу в [рандомне_місто]". Дивіться пункт 2 ;)
— Обожнюю риболовлю.
А тепер — ваша черга, розкажіть трохи про себе в коментарях: хто ви, звідки, чому підписалися і чи любите робити свою роботу так само, як це люблю я.
А підтримати "Дивовижний світ веброзробки" можна наступним чином:
— Заохотити підписатися хоча б одного колегу, який в житті про мене не чув;
— Ставити на кожен допис як не вогник, то хоча б серденько;
— Стати патроном на BASE від monobank.
@babichdev
🔥93❤25👏6
Коротеньке оголошення:
Цього четверга буде невелика неофіційна тусовка в "Довгих бурхливих оплесках" (Львів). Не івент, не мітап — просто хто прийде, той прийде, познайомимось, поспілкуємось, потусуємось.
Можете підходити під 19 годину, я там уже точно буду.
Чекатиму!
Цього четверга буде невелика неофіційна тусовка в "Довгих бурхливих оплесках" (Львів). Не івент, не мітап — просто хто прийде, той прийде, познайомимось, поспілкуємось, потусуємось.
Можете підходити під 19 годину, я там уже точно буду.
Чекатиму!
🔥25❤7
Товариство, тим часом нам лишилося зібрати усього 27 500 гривень у нашому зборі для 109 ОГШБ 10 ОГШБр "Едельвейс"
Давайте натиснемо разом і закриємо нарешті його.
Нагадую, що кожні 50 гривень вашого донату — це квиточок в розіграші LEGO Dune Atreides Royal Ornithopter від української продуктової IT-компанії Brainstack.
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
@babichdev
Давайте натиснемо разом і закриємо нарешті його.
Нагадую, що кожні 50 гривень вашого донату — це квиточок в розіграші LEGO Dune Atreides Royal Ornithopter від української продуктової IT-компанії Brainstack.
🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ
💳 Картка mono:
4441111124390562
@babichdev
❤8🔥5
#партнерський_допис
Давайте будемо відверті — від штучного інтелекту уже нікуди не сховатися. Але й не треба, на мою думку.
А що точно треба робити просто вже, то це опанувати штучний інтелект в усіх його доступних нам проявах, і, замість нити як він забере всю роботу в світі, стрімко вриватися в майбутнє цифрових технологій вже сьогодні.
Тому я запрошую вас долучитися до AI-конференція Fwdays+DevRain, що відбудеться вже 5 липня в Києві.
Серед тем, які будуть обговорюватися: погляд Microsoft та Google на генеративний AI, що буде з вашою командою завтра, книга про генеративний AI за його допомогою, чи варто інвестувати в AI в 2025 та багато іншого.
Серед спікерів будуть Тетяна Лукинюк (Google), Олександр Краковецький (DevRain), Артем Биковець (mono, Simplesense.), Олексій Мінаков (Generative AI) та інші.
Використайте промокод
Деталі за посиланням: https://fwdays.com/event/fwdays-devrain-ai
@babichdev
Давайте будемо відверті — від штучного інтелекту уже нікуди не сховатися. Але й не треба, на мою думку.
А що точно треба робити просто вже, то це опанувати штучний інтелект в усіх його доступних нам проявах, і, замість нити як він забере всю роботу в світі, стрімко вриватися в майбутнє цифрових технологій вже сьогодні.
Тому я запрошую вас долучитися до AI-конференція Fwdays+DevRain, що відбудеться вже 5 липня в Києві.
Серед тем, які будуть обговорюватися: погляд Microsoft та Google на генеративний AI, що буде з вашою командою завтра, книга про генеративний AI за його допомогою, чи варто інвестувати в AI в 2025 та багато іншого.
Серед спікерів будуть Тетяна Лукинюк (Google), Олександр Краковецький (DevRain), Артем Биковець (mono, Simplesense.), Олексій Мінаков (Generative AI) та інші.
Використайте промокод
BABICH10 та отримайте знижку 10%Деталі за посиланням: https://fwdays.com/event/fwdays-devrain-ai
@babichdev
🔥7❤2🤔2