Відео такого формату українською мовою це свято для розвитку загальної кваліфікації кадрів на нашому ринку IT. В англомовному сегменті давно слідкую за оглядами від Hussein Nasser. Проте ваше лаконічне представлення матеріалу ще краще, бо стиль Хусейна іноді заносить у довгі не надто важливі щодо тематики відступи.
Дякую за такий відгук. Саме таку ціль й ставлю - канал, де можна отримати загальну базу й краще відчуття технологій (тому не тільки теорія, а такі міні занурення всередину на практиці). Відносно Хусейна, то він крутий - класні відео робить. Теж часом дивлюся 🙂
Неймовірно крутий канал. Дуже давно не вистачало україномовного каналу, де інженер професіонал буде валити базу, як вона є простими словами. Дякую за вашу роботу!
Супер відео. Я також задавав собі це питання та обраховував час на пінг, коли намагався зрозуміти чи буде можливість позбутися ЛАН турнірів з ксго. Все дуже печально, бо якщо банально поділити довжину екватора на 2 (~40 000/2 - найдовша відстань між двома точками на глобусі), поділити навіть на неможливі 300 000км/год та помножити на 2 (реквест+респонс), то виходять нещасні 132мс. І ситуація не сильно зміниться навіть якшо в майбутньому винайдуть інтернет, який висилатиме нейтріно через ядро землі.
З'єднання в іграх працює по сокетам, це більше схоже на юдп. Між вами та комп'ютером тільки перший раз іде обмін запит-реквест. Після чого утворюється пряме з'єднання, і вже сервер відразу відправляє вам дані, і ваш комп'ютер відправляє дані. Тобто множити на два не потрібно🙃 Звісно, 60 мс це все ще багато для кс го і батлофільдів, але жоден розробник не буде робити веб сервер на http) Максимум, це раз в деякий час може бути запит на звірку даних. Зазвичай саме під час звірки даних ви раптово помирайте за стіною, бо куля яка вас вбила десь загубилися між Лондоном та Берліном😂
Дякую за якісний контент! Розкрийте тему Congestion control і різницю між BBR та CUBIC, дуже цікаво буде отримати детальний розбір в вашому виконанні) Чому BBR не встановлений дефолтною опцією на останніх дистрибутивах тої ж самої Ubuntu)
Не думав що буде цікаво. Досить проста тема і пояснення теорії з університету на практиці. Тепер мені цікаво повторити той самий експеримент на більш складному прикладі: cloud load balancer -> kubernetes cluster -> container. Kubernetes 1.26 додав можливість більш гнучкого налаштування трафіку всередині. Подивимось як це впливає на роботу.
Число 200 000 км/с - це швидкість світла у склі, із якого зроблено оптоволоконний кабель. Не дуже відома величина, усім відома швидкість світла к вакумі трохи більша.
клас! дякую!) давайте по деталям починаючи з днс) дуже цікаво) P.S. якщо можливо і не лінь, абревіатури на кшталт syn та ack і будь-які інші розшифровуйте будь ласка хоч на їх початковому звучанні)
Дякую за якісний контент! Але, нажаль, різні хеллоуворлди та відео накшталт "Як увійти в IT після 30, 40, 50" набирають більше просмотрів та лайків. А експертиза автора при цьому потрібна набагато менша.
Є ще цікавий момент з TLS, коли використовують не стиснуті сертифікати, тобто максимально скільки може містити 1 сегмент - 1460 bytes і якщо наш сертифікат в районі 10kB, то треба буде надіслати 7 сегментів чисто щоб обмінятись сертифікатом. Не кажучи вже про різницю між TLS1.3 та попереднім, бо в 1.3 там 5 кроків (чи навіть 4), коли в 1.2 їх 9.
Так, але tcp slow start починає з 10 сегментів. Тобто сервер може відправити 14k не чекаючи підтвердження від клієнта. Відповідно це не створює додаткової затримки. Але потім, коли ми передаємо http трафік, наприклад, 50k, то сервер відправить лише 14k й потім чекатиме ack від клієнта, потім відправить 28k й чекатиме ack, а потім вже решту. Й відповідно тут вже виникають додаткові затримки на очікування ack
@@AboutProgramming Цікаво. Тобто якщо я правильно зрозумів, то tls сертифікат при https establishment нам не буде заважати своїм latency/пропускною здатністю сегментів, якщо ми не стиснули сертифікати? Наче, ще пам'ятаю там з tls1.3 сертифікати самі стискаються, чи я щось вигадую)
Я персонально ніколи не розділяв ці поняття. Хоча в перших главах книги "Software Engineering at Google" різниця описана. Типу, що SWE це Development, але коли додається ще вимір часу. Тобто софт треба не тільки написати, але щось робити вродовж довгого часу. Й коли ти працюєш й з цією додатковою змінною, то це software engineering. Дле мене всі ці дискусії про кодер, девелопер, софтваре інженер - це щось штучне й що не має сенсу :)
Тут скоріше питання, що можна подивитися на мережевому рівні, а чи як налаштували фільтри в Wireshark це вже вторинне. Але як буду розбирати усілякі мережеві штуки, то буде трохи про Wireshark або tcpdump
Так, якщо з'єднання вже існує, то у нас немає хендщейків більше. Також в HTTP 1.1 на кожен запит окреме з'єднання, а в HTTP 2 одне з'єднання на багато запитів. Але все одно нічого не зробити, щоб раундріп займав менше 100мс (Україна - Каліфорнія), оскільки це обмеження швидкості світла
Загалом дуже круто, але ви почали про відстань до США, єдине що цікаво наскільки буде відрізнятись якшо буде сервер в сша або десь ближче:) Яка різниця в часі
Це легко порахувати. Достатньо просто зробити ping сервера й далі, знаючи один round trip, можна рахувати все інше. Наприклад, до Франкфурта пінг десь 40мс
Грати можна, але питання пінгу. На жаль ми обмежені швидкостю світла й ніколи не буде пінг з США, такий як з Європою, який би прогрес в технологіях не був би. Й якщо треба відправити пакет на відстань в 10тис км, то туди й назад раундтріп займе 100мс в оптоволокні (200тис км на секунду). Швидкість світла в вакуумі 300тис км на секунду, тобто по прямій в вакуумі теоретично можна зменшити пінг в 1.5 рази, але далі неможливо навіть теоретично щось зробити
Дуже цікава тема також є безпека у web як XSS, CSRF і тд. Як будете шукати наступні теми для відео то можете це взяти в роботу. Що таке приклад і як боротися. Дякую
Відео супер. Акурат, щоб я зрозумів😂. На рахунок затримок. Мені завди здавалося, що затримаи пакетів/запитів у схемах маршрутизації мали б бути суттєвішими..
Дякую. А ще оптичне волокно у волоконно-оптичному кабелі розташоване з повивом навколо центрального силового елементу і оптична довжина є більше ніж довжина кабелю, а ще кабель прокладений не по прямій лінії, а ще Вам дуже пощастило що немає ділянки мобільного зв'язку або супутникового бо тоді пінг показав би що сервер десь на Місяці. А так дуже професійно і просто все пояснюєте (ну як на мою думку інженера зв'язку відділу планування магістральної мережі одного з мобільних операторів в Україні). Прошу продовження...
Добрий день ще раз! в мене таке питання як ви ставитесь до того щоб виступити з якимось воркшопом для Summer IT camp для факультету комп'ютерних наук та кібернетики КНУ ім. Тараса Шевченка?
Дякую за відос! В ріалтайм іграх навіть якщо вони по UDP ганяють байтики, я не можу пояснити 140 пінг між Украиною та US West, чи може проблема у вбудованому лічильнику пінга і насправді він більший?
Ідеальна ситуація 100 мс на 10тис км раундтріп. На практиці пінг більший, оскільки є додаткові затримки, але кабеля під атлантикою лежать практично по прямій. Тобто маршрут Євпропа - захід США практично прямий, тому на один раундтріп 140мс це реально. В цілому можна очіукати на рандтріп від 1.2x до 2x від ідеальної ситуації в залежності від маршруту (чи по прямій чи в обхід), кількості проміжних вузлів, навантаження на мережу й так далі. www.submarinecablemap.com/
дуже дуже дякую. Цей канал як скарб для бек ендера : )) На співбесідах просять як можна найбільш детальніше пояснити що відбувається з момента введення в браузері url і до того як браузер відображає сторінку. Ці відео це пряме попадання. Дякую ще раз 👍👍👍
@@AboutProgramming Беремо 2 запутані частинки. Стандартно вони поводять себе як хвиля. Це буде State 0. Коли ми намагаємось спостерігати за однією із них - вони обидва стають State 1 (поводять себе як частинки). Тобто в Києві кодуємо одну з них, а в ЛА - маємо готовий результат) Здається це так працює)
@@hryhoriinevmerzhytskyi4299 спочатку треба передати частинки в LA й це буде зі швидкістю світла. Окрім того ми не знаємо в який стан (дивимось на спін) вони прийдуть після спостереження (це якійсь рандом). Також якщо ми подивилися одну частинку в Києві, то звідки ми знаємо, що вже час подивитися сплутану частинку в LA (теж треба передати сигнал по мережі, що вже пора глянути)
@@AboutProgramming А якщо це буде 2 p2p-пристрої з двома каналами (по типу RX/TX), тоді ми можемо один залишити в Києві, а другий в LA Новою Поштою відправити)) А технічні питання оці дядьки знають, мені так здається: Нобелівську премію з фізики за 2022 рік присудили "за експерименти із заплутаними фотонами, встановлення порушення нерівностей Белла та відкриття квантової інформаційної науки". Якщо коротко - ми змінюєм стан RX, TX це фіксує). Оце я з Вами спілкуюсь, а сам думаю: "Це ж ви в великому Google працюєте. Ви ж можете таке і провернути ))))"
Відео такого формату українською мовою це свято для розвитку загальної кваліфікації кадрів на нашому ринку IT. В англомовному сегменті давно слідкую за оглядами від Hussein Nasser. Проте ваше лаконічне представлення матеріалу ще краще, бо стиль Хусейна іноді заносить у довгі не надто важливі щодо тематики відступи.
Дякую за такий відгук. Саме таку ціль й ставлю - канал, де можна отримати загальну базу й краще відчуття технологій (тому не тільки теорія, а такі міні занурення всередину на практиці). Відносно Хусейна, то він крутий - класні відео робить. Теж часом дивлюся 🙂
Також слухаю Hussein Nasser, думав купити його курси на юдемі, але почитав відгуки що подача матеріалу не структурована)
Віктор, дякую за відео, дуже класно що теоретичну частину Ви одразу підкріплюєте практикою, людям які вперше про це чують, буде неймовірно корисно!
Це зараз, мабуть, мій улюблений канал на ютубі
Згоден)
Крутий канал з цікавою подачею матеріалу та темами
просто бомба, особливо частина з wire shark. дуже, дуже дякую!
Просто вау! Я ще не бачив щоб хтось так круто пояснював - як працює інтернет. Дякую за матеріал
Неймовірно крутий канал. Дуже давно не вистачало україномовного каналу, де інженер професіонал буде валити базу, як вона є простими словами. Дякую за вашу роботу!
😇
Супер відео. Я також задавав собі це питання та обраховував час на пінг, коли намагався зрозуміти чи буде можливість позбутися ЛАН турнірів з ксго. Все дуже печально, бо якщо банально поділити довжину екватора на 2 (~40 000/2 - найдовша відстань між двома точками на глобусі), поділити навіть на неможливі 300 000км/год та помножити на 2 (реквест+респонс), то виходять нещасні 132мс. І ситуація не сильно зміниться навіть якшо в майбутньому винайдуть інтернет, який висилатиме нейтріно через ядро землі.
розмістивши сервер в центрі відрізка AB теоритично можна збільшити швидкість в 2 рази, оскільки обидва клієнта будуть мати AB/2 відстань до сервера
З'єднання в іграх працює по сокетам, це більше схоже на юдп. Між вами та комп'ютером тільки перший раз іде обмін запит-реквест. Після чого утворюється пряме з'єднання, і вже сервер відразу відправляє вам дані, і ваш комп'ютер відправляє дані. Тобто множити на два не потрібно🙃
Звісно, 60 мс це все ще багато для кс го і батлофільдів, але жоден розробник не буде робити веб сервер на http)
Максимум, це раз в деякий час може бути запит на звірку даних. Зазвичай саме під час звірки даних ви раптово помирайте за стіною, бо куля яка вас вбила десь загубилися між Лондоном та Берліном😂
Нещодавно натрапив на цей канал, дякуючи алгоритмам ютубу. Багато нового дізнаюсь, дякую. Продовжуйте в тому ж дусі)
Дуже будем вдячні за продовження! Дуже просто і інформативно, лайк!
Супер, не очікував у цьому відео чогось нового, але отримав, як мінімум, новий інструмент для роботи
Дякую за якісний контент! Розкрийте тему Congestion control і різницю між BBR та CUBIC, дуже цікаво буде отримати детальний розбір в вашому виконанні)
Чому BBR не встановлений дефолтною опцією на останніх дистрибутивах тої ж самої Ubuntu)
Дакую! Комент в підтримку👍
Контент супер. Потрібно ще про arp і базові мережеві протоколи.
Класс, дивлюсь усі, щось знаю, щось нове. Також глянув твое інтревью с Юрою, теж лайк
Настільки звичайне лого та назва каналу, при такому шикарному контенту!
Гірше, коли навпаки))
Бійтеся бога, на світі дуже мало речей крутіших за Гіпножабу
Прекрасний контент, для розуміння процесу
Вітаю. Чекаю на продовження. Цікава та корисна інформація
Супер. Дякую.
супер крутий відос. дякую
Кайф
Дуже зрозуміло і доступно
дуже крута подача інформації, дякую
Шикарно. Роби ще.
Не думав що буде цікаво. Досить проста тема і пояснення теорії з університету на практиці. Тепер мені цікаво повторити той самий експеримент на більш складному прикладі: cloud load balancer -> kubernetes cluster -> container.
Kubernetes 1.26 додав можливість більш гнучкого налаштування трафіку всередині. Подивимось як це впливає на роботу.
Так тримати!!!
Число 200 000 км/с - це швидкість світла у склі, із якого зроблено оптоволоконний кабель.
Не дуже відома величина, усім відома швидкість світла к вакумі трохи більша.
Продовжуй всі розпочаті теми!!! Дуже класно виходить!!
❤БлагоДарю
Кайфове поєднання теорії з практикою Було б дуже круто продовження в такому ж форматі про CDN
Круто дякую. Але хочу зауважити, що за назвою в житті б не зрозумів, що це відео про те як працює інтернет. А перейшов вже з наступного відео.
дякую за контент, чекаю більше контенту)
Дуже класна подача матеріала. Особливо радує, що такого рівня контент додають українською мовою. Дякую. Відразу в обране.
Круте пояснення! Плюсую за продовження :)
Дуже дякую! Чекаю на наступне відео з ціі серії!
клас! дякую!) давайте по деталям починаючи з днс) дуже цікаво)
P.S. якщо можливо і не лінь, абревіатури на кшталт syn та ack і будь-які інші розшифровуйте будь ласка хоч на їх початковому звучанні)
Дякую за відгук. Так, про скорочення й абревіатури гарна ідея. Буду робити 🙂
Топовий контент топовою мовою, дякую
Ну це шик і дим :)
Дякую за якісний контент! Але, нажаль, різні хеллоуворлди та відео накшталт "Як увійти в IT після 30, 40, 50" набирають більше просмотрів та лайків. А експертиза автора при цьому потрібна набагато менша.
Це фантстика! Давайте ще 🤯
Хороший контент.
Дуже корисно
Мій новий любимий канал
Ви найкращий дякую за контент! Розкажіть про сертифікати ssl/tls)
Дякую! Про ssl/tls буде обов'язково 🙂
Гарно, дякую
мені дуже цікаво було б послухати про порівняння нереляційних баз даних та їх порівняння з реаляційними і коли яку краще використовувати
Є ще цікавий момент з TLS, коли використовують не стиснуті сертифікати, тобто максимально скільки може містити 1 сегмент - 1460 bytes і якщо наш сертифікат в районі 10kB, то треба буде надіслати 7 сегментів чисто щоб обмінятись сертифікатом.
Не кажучи вже про різницю між TLS1.3 та попереднім, бо в 1.3 там 5 кроків (чи навіть 4), коли в 1.2 їх 9.
Так, але tcp slow start починає з 10 сегментів. Тобто сервер може відправити 14k не чекаючи підтвердження від клієнта. Відповідно це не створює додаткової затримки. Але потім, коли ми передаємо http трафік, наприклад, 50k, то сервер відправить лише 14k й потім чекатиме ack від клієнта, потім відправить 28k й чекатиме ack, а потім вже решту. Й відповідно тут вже виникають додаткові затримки на очікування ack
@@AboutProgramming Цікаво. Тобто якщо я правильно зрозумів, то tls сертифікат при https establishment нам не буде заважати своїм latency/пропускною здатністю сегментів, якщо ми не стиснули сертифікати?
Наче, ще пам'ятаю там з tls1.3 сертифікати самі стискаються, чи я щось вигадую)
Було би добре пояснити різницю TCP/IT та HTTP.
А так дякую за пояснення хендшейку.
Є в плані ціле відео, де розберемо це на прикладі
@AboutProgramming Було би круто побачити відео де пояснюється різниця developer та software engineer. І як стати саме software engineer-ом
Я персонально ніколи не розділяв ці поняття.
Хоча в перших главах книги "Software Engineering at Google" різниця описана. Типу, що SWE це Development, але коли додається ще вимір часу. Тобто софт треба не тільки написати, але щось робити вродовж довгого часу. Й коли ти працюєш й з цією додатковою змінною, то це software engineering.
Дле мене всі ці дискусії про кодер, девелопер, софтваре інженер - це щось штучне й що не має сенсу :)
@@AboutProgramming дуже дякую за швидку відповідь! Контент у вас супер
Дякую за відео. Було би цікаво більш глибоко розкрити тему самого wireshark, тому що це дуже потужний інструмент з яким треба вчитись працювати.
Тут скоріше питання, що можна подивитися на мережевому рівні, а чи як налаштували фільтри в Wireshark це вже вторинне. Але як буду розбирати усілякі мережеві штуки, то буде трохи про Wireshark або tcpdump
@@AboutProgramming дякую, будемо чекати
Интересно, спасибо!
Чікарно
Наша швидкосвітлість недостатня)
Цікаво, дякую. Але якщо реквестів на той же сервер буде багато, то ситуація буде краща? Я про https i tcp витрати.
Так, якщо з'єднання вже існує, то у нас немає хендщейків більше. Також в HTTP 1.1 на кожен запит окреме з'єднання, а в HTTP 2 одне з'єднання на багато запитів. Але все одно нічого не зробити, щоб раундріп займав менше 100мс (Україна - Каліфорнія), оскільки це обмеження швидкості світла
Як робиться така UML діаграма? Це якесь розширення для VSCode?
Plantuml й плагін під vscode
Загалом дуже круто, але ви почали про відстань до США, єдине що цікаво наскільки буде відрізнятись якшо буде сервер в сша або десь ближче:) Яка різниця в часі
Це легко порахувати. Достатньо просто зробити ping сервера й далі, знаючи один round trip, можна рахувати все інше. Наприклад, до Франкфурта пінг десь 40мс
Цікаво послухати про DNS, його ієрархію.
Замовник: чому у нас тормозить сайт?
Я:
😁
Продовжуй! Дуже прошу)
DHCP, про роутери і гейтвей
Класс! Спасибо, Виктор! Расскажите про http и hhtps, пожалуйста
Не зрозумів, тобто реально не можна грати в шутери із американцями?
Грати можна, але питання пінгу. На жаль ми обмежені швидкостю світла й ніколи не буде пінг з США, такий як з Європою, який би прогрес в технологіях не був би. Й якщо треба відправити пакет на відстань в 10тис км, то туди й назад раундтріп займе 100мс в оптоволокні (200тис км на секунду). Швидкість світла в вакуумі 300тис км на секунду, тобто по прямій в вакуумі теоретично можна зменшити пінг в 1.5 рази, але далі неможливо навіть теоретично щось зробити
Я завжди казав, що світло повільне в відео!)
А люді думали, що Андрюха геть здурів: от нарешті хтось скурпульозно все порахував!
dns over https
😂
Розкажіть мені про затримку в мережі, коли на проекті запит до БД відпрацьовує 3хв
😂
Ну, якщо це генерація звітів на окремому сервері, то це може бути ок)
ого
Дуже цікавий відос👍
Дуже цікава тема також є безпека у web як XSS, CSRF і тд. Як будете шукати наступні теми для відео то можете це взяти в роботу. Що таке приклад і як боротися. Дякую
Так, про безпеку можна цілу серію зробити
не очікував такої підстави від швидкості світла))) проду))
Відео супер. Акурат, щоб я зрозумів😂. На рахунок затримок. Мені завди здавалося, що затримаи пакетів/запитів у схемах маршрутизації мали б бути суттєвішими..
Дуже цікаво, звісно продовжувати.
Дуже дякую за відео! З нетерпінням чекаємо "як працює інтернет". Цікаво дізнатись більше про TCP, UDP. Про модель OSI також
Комент в підтримку😍
Дякую❤
Оце кайф контент, дякую
Круто, дякую за відео
Дякую. А ще оптичне волокно у волоконно-оптичному кабелі розташоване з повивом навколо центрального силового елементу і оптична довжина є більше ніж довжина кабелю, а ще кабель прокладений не по прямій лінії, а ще Вам дуже пощастило що немає ділянки мобільного зв'язку або супутникового бо тоді пінг показав би що сервер десь на Місяці. А так дуже професійно і просто все пояснюєте (ну як на мою думку інженера зв'язку відділу планування магістральної мережі одного з мобільних операторів в Україні). Прошу продовження...
Це дуже круто) дякую
давай далі, дуже крута тема
Чудовий канал
класно !
Дуже класне відео. Дуже подобаються приклади. Я нещодавно принтеру надсилала ping 😂
Дякую) Буде ще продовження
Можна більше деталей про TCP slow start і як це працює?
Дуже класне пояснення! Звісно потрібно продовження! Бумбласочка
- Чому сайт тормозить?
- Та то швидкість світла замала.
- Так ще підрядники не обгрунтовували чому варто збільшувати бюджет на проект...
😁
Добрий день ще раз! в мене таке питання як ви ставитесь до того щоб виступити з якимось воркшопом для Summer IT camp для факультету комп'ютерних наук та кібернетики КНУ ім. Тараса Шевченка?
Добрий день. Можна спробувати 🙂 Пишіть мені в телеграм на @koorchik
ну йомайо)) треба вже патреон, так далі не піде!
Супер, дякую за роботу!
😁Зроблю)
Дякую за відос!
В ріалтайм іграх навіть якщо вони по UDP ганяють байтики, я не можу пояснити 140 пінг між Украиною та US West, чи може проблема у вбудованому лічильнику пінга і насправді він більший?
Ідеальна ситуація 100 мс на 10тис км раундтріп. На практиці пінг більший, оскільки є додаткові затримки, але кабеля під атлантикою лежать практично по прямій. Тобто маршрут Євпропа - захід США практично прямий, тому на один раундтріп 140мс це реально. В цілому можна очіукати на рандтріп від 1.2x до 2x від ідеальної ситуації в залежності від маршруту (чи по прямій чи в обхід), кількості проміжних вузлів, навантаження на мережу й так далі.
www.submarinecablemap.com/
Потужно!
Круто🎉
Ааа, круто!!
+
дуже дуже дякую. Цей канал як скарб для бек ендера : )) На співбесідах просять як можна найбільш детальніше пояснити що відбувається з момента введення в браузері url і до того як браузер відображає сторінку. Ці відео це пряме попадання. Дякую ще раз 👍👍👍
Дякую за відгук. Це тільки перше відео із серії про це. Буде ще)
Коли вже будуть квантові модеми з запутаними частинками?
Воно ж не допоможе)
@@AboutProgramming Беремо 2 запутані частинки. Стандартно вони поводять себе як хвиля. Це буде State 0. Коли ми намагаємось спостерігати за однією із них - вони обидва стають State 1 (поводять себе як частинки). Тобто в Києві кодуємо одну з них, а в ЛА - маємо готовий результат) Здається це так працює)
@@hryhoriinevmerzhytskyi4299 спочатку треба передати частинки в LA й це буде зі швидкістю світла. Окрім того ми не знаємо в який стан (дивимось на спін) вони прийдуть після спостереження (це якійсь рандом). Також якщо ми подивилися одну частинку в Києві, то звідки ми знаємо, що вже час подивитися сплутану частинку в LA (теж треба передати сигнал по мережі, що вже пора глянути)
@@AboutProgramming
А якщо це буде 2 p2p-пристрої з двома каналами (по типу RX/TX), тоді ми можемо один залишити в Києві, а другий в LA Новою Поштою відправити))
А технічні питання оці дядьки знають, мені так здається:
Нобелівську премію з фізики за 2022 рік присудили "за експерименти із заплутаними фотонами, встановлення порушення нерівностей Белла та відкриття квантової інформаційної науки".
Якщо коротко - ми змінюєм стан RX, TX це фіксує).
Оце я з Вами спілкуюсь, а сам думаю: "Це ж ви в великому Google працюєте. Ви ж можете таке і провернути ))))"
Розкажіть будь ласка про Edge functions (питання на хвилях NextJS/Vercel)
Крутий канал.Цікава інформація.
Дякую!
Дуже круто! Приємно отримувати нові знання від людей які мають досвід!
Дуже, дуже корисно. Дякую
Дякую за такий кльовий контент!
Круто! Дізнався щось нове! Класно що показуєте як працюєте в консолі.
Ніколи нат цим не задумувався. Крутий розбір поняття швидкості інтернету.
Дякую за простий, але наглядний приклад. Захотілося йти і читати далі про ці всі штуки. 👍