Доброго ранку, товариство.
Так, ніби з поїздками поки все, але від того мій розклад щось не стає легшим. Навпаки, я тепер вдома буду як електровіник крутитися.
Поки очухуюсь від ФанКону, пробую зібрати докупи усе, що маю зробити і написати, тому, швидше за все, нічого не буду робити і писати, а буду сумно прокрастинувати, уявляючи, як я все роблю і пишу.
Але тим не менш. Цього четверга запрошую вас на перші лампові дебати у Львові: https://t.iss.one/it_lampa/61
Я там буду модератором. І що супер важливо: квитків усього 20, лишилося усього 7, більше не буде, і запису не буде, і стриму не буде. Ексклюзив, в общім.
Буду радий вас бачити!
Так, ніби з поїздками поки все, але від того мій розклад щось не стає легшим. Навпаки, я тепер вдома буду як електровіник крутитися.
Поки очухуюсь від ФанКону, пробую зібрати докупи усе, що маю зробити і написати, тому, швидше за все, нічого не буду робити і писати, а буду сумно прокрастинувати, уявляючи, як я все роблю і пишу.
Але тим не менш. Цього четверга запрошую вас на перші лампові дебати у Львові: https://t.iss.one/it_lampa/61
Я там буду модератором. І що супер важливо: квитків усього 20, лишилося усього 7, більше не буде, і запису не буде, і стриму не буде. Ексклюзив, в общім.
Буду радий вас бачити!
Telegram
ІТ спільнота ЛАМПА
11 червня ЛАМПА робить дебати. Не панельку, не доповідь — саме дебати. Двоє людей, дві протилежні позиції.
Тема: «Спеціалісти vs Дженералісти»
За дженералістів топить Дмитро Брагінець — Engineering Manager в UINNO. Каже, що вузька спеціалізація — це пастка…
Тема: «Спеціалісти vs Дженералісти»
За дженералістів топить Дмитро Брагінець — Engineering Manager в UINNO. Каже, що вузька спеціалізація — це пастка…
🔥12❤5
#css_in_action
Користувацькі CSS-функції уже майже за рогом, тож прийшов час поглянути на них дещо ближче.
Сучасний CSS дозволяє вирішувати усе складніші задачі, зокрема через певну реактивність, закладену у CSS змінних, себто CSS custom properties, та широкий спектр нативних CSS-функцій на кшталт
Проте досі перевикористання таких виразів лишається болючою скалкою в дупі. Ми вимушені писати таку логіку наново в усіх місцях, де вона нам потрібна, що, погодьтеся, дещо незручно. Однак надія є, і вже досить давно в роботі знаходиться специфікація CSS Functions and Mixins Module Level 1, хоча й у статусі Working Draft.
Зокрема, цей документ вводить поняття CSS custom functions, які покликані саме для того, аби дати можливість створювати власні функції та перевикористовувати складні математичні формули. А вони в CSS дійсно складні, хоча б через свій синтаксис, але шо тут вже вдієш.
Виглядають вони приблизно ось так:
Синтаксис простий:
- Оголошуємо через at-rule
- Назва має префікс
- Функція може приймати параметри;
- Параметри можуть мати значення за замовчуванням:
- Параметри можна типізувати:
- Параметр може бути списком:
- Ключове слово
Можна навіть писати досить складну (наскільки це можливо) логіку. Наприклад, створювати проміжні змінні з власними розрахунками чи просто як константи:
Ба більше, користувацькі функції підтримують медіа-запити:
та умовну функцію
Що по підтримці? Ну, поки трошки сумно. Реалізацію поточного драфту для custom functions викотив Chromium, що означає, що ми можемо спробувати цей синтаксис в Chrome, Edge та решті хроміум-зоопарку.
Firefox, як і завжди, певно не спішитиме з імплементацією допоки стандарт не перейде до стабільнішого рівня, а щодо Safari впевненим можна бути лише в одному — що ми не можемо бути в ньому впевненими.
Я, насправді, дуже чекаю коли CSS custom functions увійдуть до Baseline, бо це, насправді, дуже зручна можливість. До речі, рука в руку з ними йде й чернетка CSS mixins, на які я теж чекаю. Про міксіни поговоримо згодом, коли до них дійдуть руки хоча б у Chromium, але маю сподівання, що чекати лишилося недовго.
Чого я з таким нетерпінням чекаю на момент, коли ці специфікації увійдуть до Baseline? Бо це означатиме початок забуття SCSS та всіляких інших LESS, до яких я відчуваю безпідставну та пекучу неприязнь. А якщо цей допис набере бодай 100 реакцій, то я розповім чому. А як не набере, то не розповім.
@babichdev
***
Що почитати:
MDN: @function CSS at-rule
MDN: Using CSS custom functions
Що почитати душнілам:
W3C: CSS Functions and Mixins Module
P.S. Товариство, дуже сподіваюсь, що у вас все добре, наскільки це може бути.
Росія — кончена країна кончених людей.
Тримаймося.
Користувацькі CSS-функції уже майже за рогом, тож прийшов час поглянути на них дещо ближче.
Сучасний CSS дозволяє вирішувати усе складніші задачі, зокрема через певну реактивність, закладену у CSS змінних, себто CSS custom properties, та широкий спектр нативних CSS-функцій на кшталт
clamp(), color-mix() та інших. І тепер ми можемо створювати доволі хитромудрі вирази на кшталт:clamp(var(--min), 2vw + 1rem, var(--max));
Проте досі перевикористання таких виразів лишається болючою скалкою в дупі. Ми вимушені писати таку логіку наново в усіх місцях, де вона нам потрібна, що, погодьтеся, дещо незручно. Однак надія є, і вже досить давно в роботі знаходиться специфікація CSS Functions and Mixins Module Level 1, хоча й у статусі Working Draft.
Зокрема, цей документ вводить поняття CSS custom functions, які покликані саме для того, аби дати можливість створювати власні функції та перевикористовувати складні математичні формули. А вони в CSS дійсно складні, хоча б через свій синтаксис, але шо тут вже вдієш.
Виглядають вони приблизно ось так:
@function --fluid-size(--min, --max) {
result: clamp(var(--min), 2vw + 1rem, var(--max));
}
…
font-size: --fluid-size(1rem, 3rem);Синтаксис простий:
- Оголошуємо через at-rule
@function;- Назва має префікс
--, як і решта синтаксису для користувацьких властивостей в CSS;- Функція може приймати параметри;
- Параметри можуть мати значення за замовчуванням:
--fn(--x: 1px) {…};- Параметри можна типізувати:
--fn(--clr <color>) {…}- Параметр може бути списком:
--fn(--list <length>#), width: --fn({1px, 7px, 2px}) (саме так, з фігурними дужками);- Ключове слово
result є, по суті, відповідником нашого улюбленого return;Можна навіть писати досить складну (наскільки це можливо) логіку. Наприклад, створювати проміжні змінні з власними розрахунками чи просто як константи:
@function --fluid-size(--min: 1rem, --max: 3rem) {
--preferred: calc(2vw + 1rem);
--safe-min: max(var(--min), 0.875rem);
result: clamp(var(--safe-min), var(--preferred), var(--max));
}Ба більше, користувацькі функції підтримують медіа-запити:
@function --narrow-wide(--narrow, --wide) {
result: var(--wide);
@media (width < 700px) {
result: var(--narrow);
}
}та умовну функцію
if(), яку варто розібрати окремо.Що по підтримці? Ну, поки трошки сумно. Реалізацію поточного драфту для custom functions викотив Chromium, що означає, що ми можемо спробувати цей синтаксис в Chrome, Edge та решті хроміум-зоопарку.
Firefox, як і завжди, певно не спішитиме з імплементацією допоки стандарт не перейде до стабільнішого рівня, а щодо Safari впевненим можна бути лише в одному — що ми не можемо бути в ньому впевненими.
Я, насправді, дуже чекаю коли CSS custom functions увійдуть до Baseline, бо це, насправді, дуже зручна можливість. До речі, рука в руку з ними йде й чернетка CSS mixins, на які я теж чекаю. Про міксіни поговоримо згодом, коли до них дійдуть руки хоча б у Chromium, але маю сподівання, що чекати лишилося недовго.
Чого я з таким нетерпінням чекаю на момент, коли ці специфікації увійдуть до Baseline? Бо це означатиме початок забуття SCSS та всіляких інших LESS, до яких я відчуваю безпідставну та пекучу неприязнь. А якщо цей допис набере бодай 100 реакцій, то я розповім чому. А як не набере, то не розповім.
@babichdev
***
Що почитати:
MDN: @function CSS at-rule
MDN: Using CSS custom functions
Що почитати душнілам:
W3C: CSS Functions and Mixins Module
P.S. Товариство, дуже сподіваюсь, що у вас все добре, наскільки це може бути.
Росія — кончена країна кончених людей.
Тримаймося.
❤59🔥13
Коли захтілось ввечері чучуть покодить:
2020 — pet-project
2026 — ✨SaaS✨
2020 — pet-project
2026 — ✨SaaS✨
😁84❤3
Бравзер прощає дуже багато помилок вашому HTML-документу.
Зумовлено це, в першу чергу, принципом зворотної сумісності — веб повинен працювати, навіть якщо ваш документ — дрімуче легасі. І для цього бравзер змушений "додумувати" елементи, щоб побудувати валідне DOM-дерево з того, що ви йому прислали.
Правил для такої поблажливості існує дуже багато, тож я не буду намагатися розказати про всі, а лишень огляну основні принципі такої "незламності".
Ви можете написати в .html файлі просто:
і бравзер перетворить це на:
Бо DOM-дерево мусить мати кореневий елемент, мусить мати
Важливий момент — бравзер при цьому нічого не робить саме з вашим
Так от. У бравзера є багато правил, за якими він обробляє ваш
Наприклад, необовʼязкові закриваючі теги. В певних випадках ви можете не писати їх через те, як певні елементи взаємодіють між собою. Візьмемо приклад:
Бравзер явно перетворить це на два параграфи:
Чому? Бо параграф не може містити блочні елементи всередині себе, тому, зустрічаючи відкриваючий тег для блочного елементу після відкриваючого
Це перетвориться на:
Хід "думок" приблизно такий: "так, ось параграф, шо там далі? О, div, значить p треба закрить. Так, div закінчився, шо там далі? Закриваючий p? А шо він закриває? Непорядок! У мене попередньо все закрите, тому тут буде просто параграф. Пустий."
До речі, просто текст бравзер не перетворює автоматично на параграф, а створює текстовий вузол, який цілком собі є повноправним учасником DOM.
І так, бравзер не вгадує, що ви там мали на увазі. У нього є дуже чіткі правила і механізми "відновлення", за якими він будує DOM так, щоб мати можливість відобразити бодай щось.
Якщо розмітка неповна, суперечлива або просто написана не так, як очікує парсер, бравзер не зупиняється. Він намагається зібрати з цього валідну внутрішню структуру документа. Десь він неявно створює бракуючі елементи, десь закриває відкриті раніше, десь переносить вузли в інше місце, десь ігнорує те, що не може нормально вбудувати в дерево.
Тому памʼятайте, якщо щось є в
В цьому немає нічого містичного чи непередбачуваного, усі аномалії в DOM зʼявляються чітко згідно внутрішніх правил.
До речі, так було не завжди, і свого часу була спроба запровадити стандарт XHTML, який передбачав дуже строгий синтаксис, і бравзер дуже драматично падав від помилок парсингу. Але це нікому не сподобалося чомусь, і стандарт не прижився. Натомість ми маємо HTML5, що і друзів розуміє, і ворогів уміє прощати. Ну себто ваш кучерявий і неправильний HTML.
Якщо коротко: бравзер має величезну кількість правил, трюків, виключень і алгоритмів, щоб змусити ваш HTML-документ відобразитися у вікні переглядача бодай якось замість звалитися з помилкою. Бо сторінка з 1991 року має відображатися і в 2026 році попри все.
Ось такий веб дбайливий щодо свого спадку.
@babichdev
Зумовлено це, в першу чергу, принципом зворотної сумісності — веб повинен працювати, навіть якщо ваш документ — дрімуче легасі. І для цього бравзер змушений "додумувати" елементи, щоб побудувати валідне DOM-дерево з того, що ви йому прислали.
Правил для такої поблажливості існує дуже багато, тож я не буду намагатися розказати про всі, а лишень огляну основні принципі такої "незламності".
Ви можете написати в .html файлі просто:
Hello, world!
і бравзер перетворить це на:
#el(html)
#el(head)
#el(body)
#text("Hello, world!")
Бо DOM-дерево мусить мати кореневий елемент, мусить мати
head і body. І йому простіше їх самому вставити, ніж драматично падати під час парсингу.Важливий момент — бравзер при цьому нічого не робить саме з вашим
.html. Він бере його за основу для побудови DOM, з якого вже в результаті утворюється відображення документу у вікні переглядача.Так от. У бравзера є багато правил, за якими він обробляє ваш
html, і суттєва їх кількість забезпечує певні "неявні" перетворення.Наприклад, необовʼязкові закриваючі теги. В певних випадках ви можете не писати їх через те, як певні елементи взаємодіють між собою. Візьмемо приклад:
<p>Hello
<p>World
Бравзер явно перетворить це на два параграфи:
#el(p)
#text("Hello")
#el(p)
#text("World")
Чому? Бо параграф не може містити блочні елементи всередині себе, тому, зустрічаючи відкриваючий тег для блочного елементу після відкриваючого
p, він робить висновок, що попередній елемент закінчився, і його пора закрить. До речі, він застосує таке виправлення, коли вам заманеться покласти div всередину p:<p>
<div></div>
</p>
Це перетвориться на:
#el(p)
#el(div)
#el(p)
Хід "думок" приблизно такий: "так, ось параграф, шо там далі? О, div, значить p треба закрить. Так, div закінчився, шо там далі? Закриваючий p? А шо він закриває? Непорядок! У мене попередньо все закрите, тому тут буде просто параграф. Пустий."
До речі, просто текст бравзер не перетворює автоматично на параграф, а створює текстовий вузол, який цілком собі є повноправним учасником DOM.
І так, бравзер не вгадує, що ви там мали на увазі. У нього є дуже чіткі правила і механізми "відновлення", за якими він будує DOM так, щоб мати можливість відобразити бодай щось.
Якщо розмітка неповна, суперечлива або просто написана не так, як очікує парсер, бравзер не зупиняється. Він намагається зібрати з цього валідну внутрішню структуру документа. Десь він неявно створює бракуючі елементи, десь закриває відкриті раніше, десь переносить вузли в інше місце, десь ігнорує те, що не може нормально вбудувати в дерево.
Тому памʼятайте, якщо щось є в
html, але чогось не видно в DOM, або воно не на тому місці, то з вірогідністю, що наближається до 100%, це діло ваших непосидючих рук, а не баг бравзера.В цьому немає нічого містичного чи непередбачуваного, усі аномалії в DOM зʼявляються чітко згідно внутрішніх правил.
До речі, так було не завжди, і свого часу була спроба запровадити стандарт XHTML, який передбачав дуже строгий синтаксис, і бравзер дуже драматично падав від помилок парсингу. Але це нікому не сподобалося чомусь, і стандарт не прижився. Натомість ми маємо HTML5, що і друзів розуміє, і ворогів уміє прощати. Ну себто ваш кучерявий і неправильний HTML.
Якщо коротко: бравзер має величезну кількість правил, трюків, виключень і алгоритмів, щоб змусити ваш HTML-документ відобразитися у вікні переглядача бодай якось замість звалитися з помилкою. Бо сторінка з 1991 року має відображатися і в 2026 році попри все.
Ось такий веб дбайливий щодо свого спадку.
@babichdev
❤40👍16🔥5
Товариство, запрошую вас на мітап у Львові!
25 червня спільнота для айтівців "ЛАМПА" разом з Ruby Labs проведе мітап про те, як змінюється роль інженера в епоху AI.
Два спікери:
🎙 Костянтин Гломозда — CTO & Co-Founder, Dym Solutions — про context engineering: як дати AI правильний контекст, щоб він перестав здогадуватись і почав реально допомагати вашій команді.
🎙 Я — про те, чи забирає AI роботу програмістів, чи це просто чергова трансформація професії, де розуміння задачі і відповідальність за результат досі залишаються за людиною.
Готуйте найгостріші питання — за найкращі розіграють браслети WHOOP і інші подарунки.
Після виступів — нетворкінг у приємній компанії, де буде чим підкріпитись і що випити.
Локація в центрі, буде анонсовано додатково.
📅 25 червня, 18:00, Львів
🎟 Участь за донат від 300 грн у фонд KOLO
Кількість місць обмежена.
Реєстрація обовʼязкова: https://luma.com/rlabs-tmlj
25 червня спільнота для айтівців "ЛАМПА" разом з Ruby Labs проведе мітап про те, як змінюється роль інженера в епоху AI.
Два спікери:
🎙 Костянтин Гломозда — CTO & Co-Founder, Dym Solutions — про context engineering: як дати AI правильний контекст, щоб він перестав здогадуватись і почав реально допомагати вашій команді.
🎙 Я — про те, чи забирає AI роботу програмістів, чи це просто чергова трансформація професії, де розуміння задачі і відповідальність за результат досі залишаються за людиною.
Готуйте найгостріші питання — за найкращі розіграють браслети WHOOP і інші подарунки.
Після виступів — нетворкінг у приємній компанії, де буде чим підкріпитись і що випити.
Локація в центрі, буде анонсовано додатково.
📅 25 червня, 18:00, Львів
🎟 Участь за донат від 300 грн у фонд KOLO
Кількість місць обмежена.
Реєстрація обовʼязкова: https://luma.com/rlabs-tmlj
❤3👍2🤔1
#нове_відео на каналі!
Цього разу з Марком, Ярославом і Анною з YouScan говорив про джунів — точніше, про те, чи справді їх ніхто не хоче брати, чи усе ж не так все страшно, і є команди, які навпаки надають їм перевагу.
Вийшла розмова про ріст усередині продукту, про синьйорів з ринку, про співбесіди без Event Loop та про те, чому “джун” — це не вирок, а радше стан, з якого треба вчасно вирости.
Приємного перегляду!
Комент, вподобайка й поширення, як завжди. Дякую ;)
https://youtu.be/UtSfAFwNl5k
Цього разу з Марком, Ярославом і Анною з YouScan говорив про джунів — точніше, про те, чи справді їх ніхто не хоче брати, чи усе ж не так все страшно, і є команди, які навпаки надають їм перевагу.
Вийшла розмова про ріст усередині продукту, про синьйорів з ринку, про співбесіди без Event Loop та про те, чому “джун” — це не вирок, а радше стан, з якого треба вчасно вирости.
Приємного перегляду!
Комент, вподобайка й поширення, як завжди. Дякую ;)
https://youtu.be/UtSfAFwNl5k
YouTube
ІТ проти ДЖУНІОРІВ? | Чи наймають сьогодні джунів і чому
Здається, джунам зараз просто неможливо отримати роботу. Компанії хочуть вже досвідчених людей, початківцям радять дорости десь самостійно, а штучний інтелект тільки додає відчуття, що місця для старту майже не лишилось. Проте всередині продукту це питання…
🔥30❤4
Дивовижний світ веброзробки pinned «#нове_відео на каналі! Цього разу з Марком, Ярославом і Анною з YouScan говорив про джунів — точніше, про те, чи справді їх ніхто не хоче брати, чи усе ж не так все страшно, і є команди, які навпаки надають їм перевагу. Вийшла розмова про ріст усередині…»
Через які теми ви слідкуєте на цим каналом?
Anonymous Poll
24%
Нові відео на YouTube
48%
HTML & CSS
59%
JavaScript
48%
Роздуми про нелегку долю айтівця
36%
Софт-скіли
63%
Мудрі проповіді про всяку архітектуру
26%
Меми
16%
По приколу просто, зараз відпишусь
😁17❤5🤔3
#про_інтернет
Одного погожого ранку Джон Сміт вирушив у мандрівку усього свого життя — він почав своє паломництво до Єрусалиму. Узявши до рук патерицю та перекинувши через плече дорожню сумку, він запитавсь в алдермена: "Як мені дістатися Єрусалиму?". На що отримав відповідь: "Спочатку дійди до Некствілю та запитайся там".
Джон докрокував до містечка, де його спрямували до Сімплтонського абатства, а там — до міста Беквотер. Далі його шлях пролягав манівцями й королівськими трактами, дорогою він відвідав безліч міст та містечок, побував у найбільших соборах Європи та бачив незліченні дива, аж поки, за пів року мандрівки, дістався місця свого призначення. І на кожній зупинці він робив завжди одне й те саме — питав дорогу до Єрусалиму, а натомість отримував керунок до наступного місця, де можна було б спитати дорогу.
Минуло сім століть, а ми з вами мандруємо світом в той же спосіб. Ну, не особисто. Коли сидимо в інтернеті. І не ми самі, а маленькі жваві пакети, якими обмінюється наш пристрій, поки ми гигикаємо над черговим тіктоком, сидячи у вбиральні.
Дійсно, подорож одного пакета надзвичайно схожа із подорожжю Джона Сміта, хіба займає тепер незрівнянно менше часу. Коли наш пристрій хоче надіслати кудись пакуночок даних, він не знає усього шляху, натомість усе, що йому відомо — це пункт призначення та найближче місце, де можна спитати дорогу. У випадку вашої локальної мережі — у вашого домашнього роутера, який недарма має таку назву. Коли пакет приходить до нього, то отримує вказівку мандрувати далі, до роутера вашого інтернет-провайдера, який направляє мандрівника далі.
І так відбувається доти, поки він не досягне мети. Протягом цієї подорожі пакет може відвідати багато різних роутерів, і жоден з них не буде знати повного шляху. Лише приблизний напрямок.
Чому? Все просто — Інтернет занадто великий. Ваш пристрій просто не може знати повний шлях до кожного сервера на планеті. Та навіть якби й знав, цей шлях може зненацька змінитися наступної миті через низку причин, як-от перевантаження ліній, аварії на вузлах, зміни в політиках провайдерів, недоступність окремих мереж або маршрутів та інші негаразди. Ну а ще різними мережами володіють різні організації, що можуть мати власні правила маршрутизації, і маршрут для нього може змінитися, бо наступні роутери почнуть спрямовувати трафік інакше.
Тому набагато ефективніше визначати подальший напрямок руху в кожній контрольній точці замість спроби дотримуватись одного-єдиного шляху. І надійніше. Якщо один шлях перестає працювати, то можна завжди дуже швидко визначити інший.
Суттєва відмінність, правда, полягає в тому, що якщо ваш пакет загубився в дорозі, то можна надіслати дані ще раз. Іноді новий пакет піде тим самим шляхом, іноді — іншим, якщо маршрути встигли змінитися. А Джон Сміт, вскочивши в халепу дорогою до Єрусалиму, так і лишився б назавжди безіменною жертвою розбійників десь в глухому закутку Богемії.
Підхід з пунктом призначення дозволяє роутерам пересилати пакети доволі швидко. Якби кожен роутер дбайливо вираховував детальний шлях для кожного окремого пакета, обмін даними займав би вічність. Роутер не вгадує напрямок приблизно, а шукає найкращий збіг у таблиці маршрутизації, після чого направляє пакет до наступної станції.
Не усі ефективні принципи мусять бути виключно новими. Іноді вони існують століттями і доводять свою ефективність у несподіваний спосіб. Чи гадав Джон Сміт колись, що те, як він мандрує світом, так добре пояснюватиме те, як цей самий світ майже миттєво обмінюється знаннями, інформацією, котиками, пропагандою і світлинами голих сідниць? Навряд чи. Хоча ідею з котиками він би точно оцінив.
@babichdev
Що почитати:
• Common Internet Network Interconnection and Charging Practices
• How to properly interpret a traceroute or MTR
• Internet History of 1960s
Одного погожого ранку Джон Сміт вирушив у мандрівку усього свого життя — він почав своє паломництво до Єрусалиму. Узявши до рук патерицю та перекинувши через плече дорожню сумку, він запитавсь в алдермена: "Як мені дістатися Єрусалиму?". На що отримав відповідь: "Спочатку дійди до Некствілю та запитайся там".
Джон докрокував до містечка, де його спрямували до Сімплтонського абатства, а там — до міста Беквотер. Далі його шлях пролягав манівцями й королівськими трактами, дорогою він відвідав безліч міст та містечок, побував у найбільших соборах Європи та бачив незліченні дива, аж поки, за пів року мандрівки, дістався місця свого призначення. І на кожній зупинці він робив завжди одне й те саме — питав дорогу до Єрусалиму, а натомість отримував керунок до наступного місця, де можна було б спитати дорогу.
Минуло сім століть, а ми з вами мандруємо світом в той же спосіб. Ну, не особисто. Коли сидимо в інтернеті. І не ми самі, а маленькі жваві пакети, якими обмінюється наш пристрій, поки ми гигикаємо над черговим тіктоком, сидячи у вбиральні.
Дійсно, подорож одного пакета надзвичайно схожа із подорожжю Джона Сміта, хіба займає тепер незрівнянно менше часу. Коли наш пристрій хоче надіслати кудись пакуночок даних, він не знає усього шляху, натомість усе, що йому відомо — це пункт призначення та найближче місце, де можна спитати дорогу. У випадку вашої локальної мережі — у вашого домашнього роутера, який недарма має таку назву. Коли пакет приходить до нього, то отримує вказівку мандрувати далі, до роутера вашого інтернет-провайдера, який направляє мандрівника далі.
І так відбувається доти, поки він не досягне мети. Протягом цієї подорожі пакет може відвідати багато різних роутерів, і жоден з них не буде знати повного шляху. Лише приблизний напрямок.
Чому? Все просто — Інтернет занадто великий. Ваш пристрій просто не може знати повний шлях до кожного сервера на планеті. Та навіть якби й знав, цей шлях може зненацька змінитися наступної миті через низку причин, як-от перевантаження ліній, аварії на вузлах, зміни в політиках провайдерів, недоступність окремих мереж або маршрутів та інші негаразди. Ну а ще різними мережами володіють різні організації, що можуть мати власні правила маршрутизації, і маршрут для нього може змінитися, бо наступні роутери почнуть спрямовувати трафік інакше.
Тому набагато ефективніше визначати подальший напрямок руху в кожній контрольній точці замість спроби дотримуватись одного-єдиного шляху. І надійніше. Якщо один шлях перестає працювати, то можна завжди дуже швидко визначити інший.
Суттєва відмінність, правда, полягає в тому, що якщо ваш пакет загубився в дорозі, то можна надіслати дані ще раз. Іноді новий пакет піде тим самим шляхом, іноді — іншим, якщо маршрути встигли змінитися. А Джон Сміт, вскочивши в халепу дорогою до Єрусалиму, так і лишився б назавжди безіменною жертвою розбійників десь в глухому закутку Богемії.
Підхід з пунктом призначення дозволяє роутерам пересилати пакети доволі швидко. Якби кожен роутер дбайливо вираховував детальний шлях для кожного окремого пакета, обмін даними займав би вічність. Роутер не вгадує напрямок приблизно, а шукає найкращий збіг у таблиці маршрутизації, після чого направляє пакет до наступної станції.
Не усі ефективні принципи мусять бути виключно новими. Іноді вони існують століттями і доводять свою ефективність у несподіваний спосіб. Чи гадав Джон Сміт колись, що те, як він мандрує світом, так добре пояснюватиме те, як цей самий світ майже миттєво обмінюється знаннями, інформацією, котиками, пропагандою і світлинами голих сідниць? Навряд чи. Хоча ідею з котиками він би точно оцінив.
@babichdev
Що почитати:
• Common Internet Network Interconnection and Charging Practices
• How to properly interpret a traceroute or MTR
• Internet History of 1960s
🔥35❤5👍1
#партнерський_допис
Товариство, тут SKELAR проводить завтра конференцію Code2Lead, головними темами якої є поточні події в tech-світі та яким буде код завтра. Вони зібрали інженерів з найсильнішою експертизою у BigTech і стартапах, аби вони поділилися з вами свом досвідом та знаннями.
Формат дуже цікавий — такий собі телеміст між Києвом та Варшавою. Відвідати подію можна буде як офлайн в одному з цих міст, так і долучитися віддалено. Участь безкоштовна, але реєстрація — обовʼязкова.
Тож, якщо ви пишете код, будуєте архітектуру, деплоїте в прод і хочете отримати практичні знання, що одразу після події можна забрати у власні проєкти — ця подія для вас.
Детальніше про спікерів та саму подію за посиланням:
https://bit.ly/3QTe3uQ
До речі, серед спікерів фахівці з Netflix, Google, Superhuman, Mono, Perply та інших великих продуктів. Тож не проґавте нагоди та долучіться завтра до конференції Code2Lead від SKELAR!
Товариство, тут SKELAR проводить завтра конференцію Code2Lead, головними темами якої є поточні події в tech-світі та яким буде код завтра. Вони зібрали інженерів з найсильнішою експертизою у BigTech і стартапах, аби вони поділилися з вами свом досвідом та знаннями.
Формат дуже цікавий — такий собі телеміст між Києвом та Варшавою. Відвідати подію можна буде як офлайн в одному з цих міст, так і долучитися віддалено. Участь безкоштовна, але реєстрація — обовʼязкова.
Тож, якщо ви пишете код, будуєте архітектуру, деплоїте в прод і хочете отримати практичні знання, що одразу після події можна забрати у власні проєкти — ця подія для вас.
Детальніше про спікерів та саму подію за посиланням:
https://bit.ly/3QTe3uQ
До речі, серед спікерів фахівці з Netflix, Google, Superhuman, Mono, Perply та інших великих продуктів. Тож не проґавте нагоди та долучіться завтра до конференції Code2Lead від SKELAR!
code2lead-2026.skelar.tech
Code2Lead Conference by SKELAR
Інженерна конференція, на якій архітектура і код розглядається крізь АІ-призму. Телеміст Київ-Варшава для тих, хто вже змінює свою щоденну роботу і прагне роби.
🔥11❤3
Доброго понеділкового ранку, товариство!
Поки канал активно набирає нових відписників, приймаю ваші побажання щодо дописів на цей тиждень.
Буду відвертим, особиста фантазія дещо підводить останнім часом, зокрема через несумісність погоди і моїх планів сходити повудити карасів. Тому делегую на вас контент-план )
До речі, хтось ще цими вихідними робитиме собі вікенд ментального здоровʼя на Карибах разом з Едвардом Кенвеєм? Там, якшо шо, ремейк AC IV виходить.
Тож гарного вам усім понеділка і продуктивного тижня вам і вашим Клодам ;)
Поки канал активно набирає нових відписників, приймаю ваші побажання щодо дописів на цей тиждень.
Буду відвертим, особиста фантазія дещо підводить останнім часом, зокрема через несумісність погоди і моїх планів сходити повудити карасів. Тому делегую на вас контент-план )
До речі, хтось ще цими вихідними робитиме собі вікенд ментального здоровʼя на Карибах разом з Едвардом Кенвеєм? Там, якшо шо, ремейк AC IV виходить.
Тож гарного вам усім понеділка і продуктивного тижня вам і вашим Клодам ;)
❤40
Товариство, вітаю.
По-перше, хочу поділитися хорошою новиною — РЕБ, на який ми з вами збирали кошти, уже місяць захищає бійців 115 ОМБр, дозволяючи їм безпечніше виконувати бойові завдання, зокрема з матеріально-технічного забезпечення підрозділів на передовій. Дякую усім, хто допоміг з цим збором!
А по-друге, знову маю до вас прохання. Підрозділ з 65-ї бригади просить допомогти з придбанням позашляхових шин для пікапа.
Сума збору — 20 000 гривень. І якби ми з вами змогли швиденько закрити його, я був би найщасливішою людиною у світі.
Посилання на банку — https://send.monobank.ua/jar/4w4LYbMRdy
Як і завжди — надзвичайно вдячний за кожен ваш донат, за кожну вашу гривню.
P.S. Я не зник, просто потрібна невеличка перерва в усьому. Я маю купу ідей для нових дописів, але банально бракує сил. Сподіваюся, це скоро мине, і нові тексти знову поллються нескінченним потоком. Не втрачайте в мене віру )
P.P.S. Якшо шо, я маю дозвіл на публікацію світлини без закритих обличь від бійців.
По-перше, хочу поділитися хорошою новиною — РЕБ, на який ми з вами збирали кошти, уже місяць захищає бійців 115 ОМБр, дозволяючи їм безпечніше виконувати бойові завдання, зокрема з матеріально-технічного забезпечення підрозділів на передовій. Дякую усім, хто допоміг з цим збором!
А по-друге, знову маю до вас прохання. Підрозділ з 65-ї бригади просить допомогти з придбанням позашляхових шин для пікапа.
Сума збору — 20 000 гривень. І якби ми з вами змогли швиденько закрити його, я був би найщасливішою людиною у світі.
Посилання на банку — https://send.monobank.ua/jar/4w4LYbMRdy
Як і завжди — надзвичайно вдячний за кожен ваш донат, за кожну вашу гривню.
P.S. Я не зник, просто потрібна невеличка перерва в усьому. Я маю купу ідей для нових дописів, але банально бракує сил. Сподіваюся, це скоро мине, і нові тексти знову поллються нескінченним потоком. Не втрачайте в мене віру )
P.P.S. Якшо шо, я маю дозвіл на публікацію світлини без закритих обличь від бійців.
❤25🔥7
Останнім часом на роботі я дрєсірую любіму абізяну. Навіть не одну, а ціле стадо. Я розробляю набір LLM агентів під мої власні задачі, і це стало одним з найцікавіших проєктів.
Тривалий час саме написання коду в рамках роботи перестало приносити задоволення, тому я зміщую свій фокус в сторону продуктового мислення та розробки рішень проблем, які переді мною стоять. Так, та сама "продуктова інженерія".
Будемо відверті — коли ти працюєш на великому проєкті з купою легасі, з усталеними практиками і всякими власними дизайн системами, місця для творчості в коді якось особливо й не лишається. Особливо, коли реалізація задач зводиться до кількох типових хуків і збірки UI з готових компонентів.
І тоді вся забава переходить в іншу площину — розробити рішення. А потім його швиденько втілити. І саме для цих цілей я й дресирую своїх цифрових абізян.
Зараз я майже майже завершив кодинг-агента, який робить те, що мені потрібно, і, що головне — так, як мені потрібно. Зараз спробую описати, що за систему я роблю взагалі, а потім вкину кілька цікавих думок, які виникли в процесі.
Я вирішив вийти трошки за рамки стандартного підходу з оркестрацією, і роблю те, що називаю харнесом, тобто комплексом спеціалізованих агентів з власними ролями.
Для щоденної роботи я маю головного агента, з яким я "спілкуюсь", ставлю задачі, сперечаюсь і називаю дурачком. Його відповідальність — такий собі менеджер, який делегує конкретні запити і задачі іншим. Інших зараз двоє: імплементатор і дослідник. Дослідник шариться по коду, джирі, документації і саме він відповідає на головні питання життя, Всесвіту і взагалі. Ну і готує детально поставлені задачі для імплементатора. А той вже бере ці задачі і… імплементує.
Ще у мене є агент для розробки інших агентів, і в процесі зараз харнес для розробки тих самих специфікацій, але фокус — завершити повсякденний харнес.
Так от що цікавого я в процесі визначив. По-перше, те, що працює для вас — цілком не працюватиме для інших. Агенти дозволяють делегувати процес. А він у кожного свій. І отут розробка такого агента дає цікаву можливість — зрозуміти свій процес для себе. Бо ви ж намагаєтесь його відгрузити на цифрові невтомні плечі вашої абізяни.
По-друге — розробка агента це теж програмування. З однією особливістю — у вас немає однієї стандартизованої мови програмування. Але основні прицнипи ті самі — якщо ви хочете передбачуваних результатів, ви повинні описувати їх так само передбачувано.
Тому у мене в агентах є роутинг, який описує типові ситуації, і що в цих ситуаціях робити, куди іти, до кого звертатися. Є описи сценаріїв, є описи дій, є навть своєрідні функції. І це все густо обмазано маленькими скілами, до яких часто роутинг і веде. І це все дуже строго обмежується, аби агент не вигадував. Нема гілки в роутингу — він завершує виконання роботи.
Ще один дуже важливий урок — ви ніколи не виправите помилку в агенті, додаючи розлогі описи і пояснення. Воно тупе. Тому у мене правило — опис бути настільки чітким і малослівним, наскільки це дозволяє інтерпретувати задачу в один єдиний спосіб. Якщо ви додаєте пояснення і приклади — ви лікуєте симптом, а не причину.
А ще я додав кілька шарів для короткострокової та середньостроковї памʼяти у вигляді mcp-сервера для sql. І абізяни самі розрулюють свої тудушки і нотатки через базу даних замість створення гігантських markdown-файлів.
Але, що найголовніше — в усьому цьому майже на кожному кроці є я. Ревʼю документації, специфікацій, код-ревʼю після кожної задачі (я під це навіть власний локальний діф-переглядач з mcp-сервером навайбірував), затвердження описів до пул-ріквестів, і так далі. І, звичайно ж, постійне, постійне покращення та виправлення самих агентів.
А ще я дуже активно використовую worktree, що дозволяє паралельно працювати над кількома задачами і жонглювати пул-ріквестами.
І при всьому цьому я не забуваю, як виглядає код, що найголовніше. Бо які б розумні не були ваші ШІшки, без нагляду вони так говноклодять, що не всяка людина так зуміє.
Поки писав, зрозумів, що про це можна цілу серію про це зробить.
Тож закриваєм збір і буде вам ;)
@babichdev
Тривалий час саме написання коду в рамках роботи перестало приносити задоволення, тому я зміщую свій фокус в сторону продуктового мислення та розробки рішень проблем, які переді мною стоять. Так, та сама "продуктова інженерія".
Будемо відверті — коли ти працюєш на великому проєкті з купою легасі, з усталеними практиками і всякими власними дизайн системами, місця для творчості в коді якось особливо й не лишається. Особливо, коли реалізація задач зводиться до кількох типових хуків і збірки UI з готових компонентів.
І тоді вся забава переходить в іншу площину — розробити рішення. А потім його швиденько втілити. І саме для цих цілей я й дресирую своїх цифрових абізян.
Зараз я майже майже завершив кодинг-агента, який робить те, що мені потрібно, і, що головне — так, як мені потрібно. Зараз спробую описати, що за систему я роблю взагалі, а потім вкину кілька цікавих думок, які виникли в процесі.
Я вирішив вийти трошки за рамки стандартного підходу з оркестрацією, і роблю те, що називаю харнесом, тобто комплексом спеціалізованих агентів з власними ролями.
Для щоденної роботи я маю головного агента, з яким я "спілкуюсь", ставлю задачі, сперечаюсь і називаю дурачком. Його відповідальність — такий собі менеджер, який делегує конкретні запити і задачі іншим. Інших зараз двоє: імплементатор і дослідник. Дослідник шариться по коду, джирі, документації і саме він відповідає на головні питання життя, Всесвіту і взагалі. Ну і готує детально поставлені задачі для імплементатора. А той вже бере ці задачі і… імплементує.
Ще у мене є агент для розробки інших агентів, і в процесі зараз харнес для розробки тих самих специфікацій, але фокус — завершити повсякденний харнес.
Так от що цікавого я в процесі визначив. По-перше, те, що працює для вас — цілком не працюватиме для інших. Агенти дозволяють делегувати процес. А він у кожного свій. І отут розробка такого агента дає цікаву можливість — зрозуміти свій процес для себе. Бо ви ж намагаєтесь його відгрузити на цифрові невтомні плечі вашої абізяни.
По-друге — розробка агента це теж програмування. З однією особливістю — у вас немає однієї стандартизованої мови програмування. Але основні прицнипи ті самі — якщо ви хочете передбачуваних результатів, ви повинні описувати їх так само передбачувано.
Тому у мене в агентах є роутинг, який описує типові ситуації, і що в цих ситуаціях робити, куди іти, до кого звертатися. Є описи сценаріїв, є описи дій, є навть своєрідні функції. І це все густо обмазано маленькими скілами, до яких часто роутинг і веде. І це все дуже строго обмежується, аби агент не вигадував. Нема гілки в роутингу — він завершує виконання роботи.
Ще один дуже важливий урок — ви ніколи не виправите помилку в агенті, додаючи розлогі описи і пояснення. Воно тупе. Тому у мене правило — опис бути настільки чітким і малослівним, наскільки це дозволяє інтерпретувати задачу в один єдиний спосіб. Якщо ви додаєте пояснення і приклади — ви лікуєте симптом, а не причину.
А ще я додав кілька шарів для короткострокової та середньостроковї памʼяти у вигляді mcp-сервера для sql. І абізяни самі розрулюють свої тудушки і нотатки через базу даних замість створення гігантських markdown-файлів.
Але, що найголовніше — в усьому цьому майже на кожному кроці є я. Ревʼю документації, специфікацій, код-ревʼю після кожної задачі (я під це навіть власний локальний діф-переглядач з mcp-сервером навайбірував), затвердження описів до пул-ріквестів, і так далі. І, звичайно ж, постійне, постійне покращення та виправлення самих агентів.
А ще я дуже активно використовую worktree, що дозволяє паралельно працювати над кількома задачами і жонглювати пул-ріквестами.
І при всьому цьому я не забуваю, як виглядає код, що найголовніше. Бо які б розумні не були ваші ШІшки, без нагляду вони так говноклодять, що не всяка людина так зуміє.
Поки писав, зрозумів, що про це можна цілу серію про це зробить.
Тож закриваєм збір і буде вам ;)
@babichdev
❤70👍12
Дивовижний світ веброзробки
Товариство, лишилось буквально трошечки добить. https://send.monobank.ua/jar/4w4LYbMRdy
Шини оплачено, дякую усім!
Вийшло навіть трошки менше, 17356грн, тож решту поки переклав в постійну банку до наступного збору.
Ще раз усім дякую, і гарних вам вихідних!
Вийшло навіть трошки менше, 17356грн, тож решту поки переклав в постійну банку до наступного збору.
Ще раз усім дякую, і гарних вам вихідних!
❤12🔥3
Дощ, чебуреки і розмови про ШІ на березі озера.
Після допису про любімих абізян, себто про ШІ-агентів, мій давній знайомий, а за сумісництвом і постійний читач, запропонував зустрітися і потеревенити на цю тему. На що я з величезним задоволенням погодився.
Це був дуже цікавий вечір, скажу я вам: ми вечеряли чудовими чебуреками під дощем, неспішно прогулювалися стежкою понад берегом, повільно намотуючи кола, і увесь час говорили.
Я люблю поговорити про якісь робочі речі в неформальній обстановці, особливо зараз, навіть дружина жартувала, мовляв, нарешті поговорив з людиною, яка розуміє, що я їй кажу. І, хоча й дійсно саме живої розмови мені дуже не вистачало, особливо цінною ця зустріч стала завдяки іншому.
Теми нашої бесіди стрибали, наче сполохані коники: від практичного застосування ШІ в роботі, від намагань зрозуміти себе і своє місце у галузі, що змінюється найстрімкіше за увесь час свого існування, до заглядання у якесь надзвичайно далеке майбутнє.
Але крутилося усе навколо одного: ми дійсно боїмося змін. В цьому ми не абсолютно відрізняємось від наших далеких родичів з якогось там раннього палеоліту. Однак ми боїмося не самих змін, ми боїмося невідомості, яку вони приносять.
І кожен з цим справляється, як може. Хтось опускає руки, хтось панічно хапається за усе підряд, хтось робить вигляд, що все зрозумів і очолює цю революцію, хтось чухає голову і розводить руками, хтось намагається змінюватись, хтось намагається змінювати.
Але усе це — реакція на шалені зміни. І це — нормально. І не існує єдиного підходу, як з цим справлятися. Якщо я почну давати поради з цього приводу, я буду як той собака в гамаку з мему "Не переживай. Нашо ти переживаєш".
І так, я теж боюсь. Спочатку я займав супер скептичну позицію щодо ШІ — цікава цяцька, побавимся, забудем. Але я не врахував, наскільки цю цяцьку можна було хайпанути. Так, я вважаю, що зараз ми просто посередині бульбашки шаленого хайпу, і вона з часом дуже гучно лусне.
Але при цьому ШІ в розробці зокрема нікуди не зникне. Зміниться, трансформується, народить нові ролі, перемеле й перемішає старі. І на світ зʼявиться щось, що ми сьогодні не в змозі осягнути.
Чи уявляли собі сучасний веб і розробку такою, як вона є, до прикладу, науковці з DARPA десь в 60-х роках? Ні, не уявляли. У них не було не те, що термінів, а навіть концепцій, які для нас сьогодні є банальними.
Тому я й не думаю про те, що буде з індустрією через 5, 10, 20 років. Я не можу хвилюватися через те, що я не можу навіть описати словами, бо я не маю ще цих самих слів.
Тож сьогодні я борюся зі своїм страхом інакше — я змінююсь. Я не кидаюсь стрімголов у прірву вайбкодинга, і не кричу "Паліть токени, а там буде видно!", але й не волаю "Паліть вайбкодерів!".
Я кажу — паліть свої стереотипи. Адаптуйтесь. Змінюйтесь. Зрозумійте, в чому ваша цінність без тих навичок, які сьогодні делегують ШІ. Розвивайте цю цінність. Вчіться.
Коли ми прогулювалися берегом, із розмови матеріалізувалась одна цікава думка: якщо, маючи умовних 15 років за плечима, ви вимірюєте свою цінність виключно в здатності писати код, то це може означати лише дві речі.
Або ви дійсно настільки глибокий фахівець, що ви пишете код, за який просто ніхто не береться, бо він вимагає якоїсь неймовірної експертизи і знань.
Або у мене для вас дуже погані новини.
Саме тому я й раджу переставати виміряти досвід роками реакту чи кількістю бібліотек для стейт-менеджменту, і нарешті почати виражати його в результатах, які відчуває продукт, над яким ви працюєте. Ось це ваш досвід.
І його ніяка шішка не замінить. Вашу чуєчку, ваше розуміння домену, ваші офігітєльні історії — ніякий, навіть надпросунутий алгортим не зможе земулювати.
Змінюйте в першу чергу ваш погляд на себе. Ми більше не можемо дозволити собі бути реакт-абізянами, і лише від кожного з нас залежить куди ми еволюціонуємо — чи станемо Homo Sapiens сингулярної епохи, а чи черговою тупиковою гілкою на задвірках історії цифрових технологій.
Ми ще багато про що розмовляли, але це вже тема для іншого допису ;)
@babichdev
Після допису про любімих абізян, себто про ШІ-агентів, мій давній знайомий, а за сумісництвом і постійний читач, запропонував зустрітися і потеревенити на цю тему. На що я з величезним задоволенням погодився.
Це був дуже цікавий вечір, скажу я вам: ми вечеряли чудовими чебуреками під дощем, неспішно прогулювалися стежкою понад берегом, повільно намотуючи кола, і увесь час говорили.
Я люблю поговорити про якісь робочі речі в неформальній обстановці, особливо зараз, навіть дружина жартувала, мовляв, нарешті поговорив з людиною, яка розуміє, що я їй кажу. І, хоча й дійсно саме живої розмови мені дуже не вистачало, особливо цінною ця зустріч стала завдяки іншому.
Теми нашої бесіди стрибали, наче сполохані коники: від практичного застосування ШІ в роботі, від намагань зрозуміти себе і своє місце у галузі, що змінюється найстрімкіше за увесь час свого існування, до заглядання у якесь надзвичайно далеке майбутнє.
Але крутилося усе навколо одного: ми дійсно боїмося змін. В цьому ми не абсолютно відрізняємось від наших далеких родичів з якогось там раннього палеоліту. Однак ми боїмося не самих змін, ми боїмося невідомості, яку вони приносять.
І кожен з цим справляється, як може. Хтось опускає руки, хтось панічно хапається за усе підряд, хтось робить вигляд, що все зрозумів і очолює цю революцію, хтось чухає голову і розводить руками, хтось намагається змінюватись, хтось намагається змінювати.
Але усе це — реакція на шалені зміни. І це — нормально. І не існує єдиного підходу, як з цим справлятися. Якщо я почну давати поради з цього приводу, я буду як той собака в гамаку з мему "Не переживай. Нашо ти переживаєш".
І так, я теж боюсь. Спочатку я займав супер скептичну позицію щодо ШІ — цікава цяцька, побавимся, забудем. Але я не врахував, наскільки цю цяцьку можна було хайпанути. Так, я вважаю, що зараз ми просто посередині бульбашки шаленого хайпу, і вона з часом дуже гучно лусне.
Але при цьому ШІ в розробці зокрема нікуди не зникне. Зміниться, трансформується, народить нові ролі, перемеле й перемішає старі. І на світ зʼявиться щось, що ми сьогодні не в змозі осягнути.
Чи уявляли собі сучасний веб і розробку такою, як вона є, до прикладу, науковці з DARPA десь в 60-х роках? Ні, не уявляли. У них не було не те, що термінів, а навіть концепцій, які для нас сьогодні є банальними.
Тому я й не думаю про те, що буде з індустрією через 5, 10, 20 років. Я не можу хвилюватися через те, що я не можу навіть описати словами, бо я не маю ще цих самих слів.
Тож сьогодні я борюся зі своїм страхом інакше — я змінююсь. Я не кидаюсь стрімголов у прірву вайбкодинга, і не кричу "Паліть токени, а там буде видно!", але й не волаю "Паліть вайбкодерів!".
Я кажу — паліть свої стереотипи. Адаптуйтесь. Змінюйтесь. Зрозумійте, в чому ваша цінність без тих навичок, які сьогодні делегують ШІ. Розвивайте цю цінність. Вчіться.
Коли ми прогулювалися берегом, із розмови матеріалізувалась одна цікава думка: якщо, маючи умовних 15 років за плечима, ви вимірюєте свою цінність виключно в здатності писати код, то це може означати лише дві речі.
Або ви дійсно настільки глибокий фахівець, що ви пишете код, за який просто ніхто не береться, бо він вимагає якоїсь неймовірної експертизи і знань.
Або у мене для вас дуже погані новини.
Саме тому я й раджу переставати виміряти досвід роками реакту чи кількістю бібліотек для стейт-менеджменту, і нарешті почати виражати його в результатах, які відчуває продукт, над яким ви працюєте. Ось це ваш досвід.
І його ніяка шішка не замінить. Вашу чуєчку, ваше розуміння домену, ваші офігітєльні історії — ніякий, навіть надпросунутий алгортим не зможе земулювати.
Змінюйте в першу чергу ваш погляд на себе. Ми більше не можемо дозволити собі бути реакт-абізянами, і лише від кожного з нас залежить куди ми еволюціонуємо — чи станемо Homo Sapiens сингулярної епохи, а чи черговою тупиковою гілкою на задвірках історії цифрових технологій.
Ми ще багато про що розмовляли, але це вже тема для іншого допису ;)
@babichdev
❤55🔥10👍3
Товариство, тут завтра у Львові буде тусовка, тож, як маєте час і натхнення — долучайтесь!
Буде смішний (сподіваюсь) стендап — про айтішників і їхню любов до ШІ;
Буде збір коштів на потреби ЗСУ;
Будуть танці — DJ set і літній open air, де можна просто відпочити, познайомитися з новими людьми та класно провести вечір.
30 липня, 17:00
«ПРОСТІР», Парк Культури
Участь за донат від 300 грн у фонд KOLO
Отут реєстрація — https://luma.com/u4s1p69b
Буде смішний (сподіваюсь) стендап — про айтішників і їхню любов до ШІ;
Буде збір коштів на потреби ЗСУ;
Будуть танці — DJ set і літній open air, де можна просто відпочити, познайомитися з новими людьми та класно провести вечір.
30 липня, 17:00
«ПРОСТІР», Парк Культури
Участь за донат від 300 грн у фонд KOLO
Отут реєстрація — https://luma.com/u4s1p69b
Luma
Builder's Summer Picnic & IT Stand-Up · Luma
Літо, нові знайомства та розмови про технології без сцени, презентацій і формальностей.
30 липня у Львові збираємо fullstack-спільноту на Builder's Summer…
30 липня у Львові збираємо fullstack-спільноту на Builder's Summer…
👍6❤3
Маю надію, всі в порядку після цієї ночі.
Задонатьте пару гривень сьогодні на якийсь збір.
Задонатьте пару гривень сьогодні на якийсь збір.
❤33