HTTP/3, QUIC и в чем революция, Джони? Часть 1

Конечно, большинство знает про одни из главных протоколов интернета HTTP и TCP, но далеко не все хорошо понимают разницу между различными версиями HTTP, а также QUIC. На этой неделе в очень общих чертах мы попробуем это исправить 🤟

1. В первом посте мы рассмотрим обновление HTTP до версии 3
2. Во втором мы подробнее поговорим, что предлагает UDP и QUIC
3. В третьем расскажем о значении всего этого для индустрии и поделимся некоторыми ценными ресурсами 🤽

Сам HTTP пережил несколько итераций и сейчас мы на пороге перехода от HTTP/2 к HTTP/3, разница между которыми следующая:

HTTP/2

📌Включает в себя user space, куда входят HTTPS в качестве App Layer и TLS в качестве Security Layer.
📌Включает hardware-determined space, куда входит TCP в качестве Transport Layer.

HTTP/3

📌Тоже включает в себя user space, но куда входит HTTPS в качестве App Layer, однако также туда входит QUICK в качестве Security Layer и Transport Layer одновременно.
📌В свою очередь, в hardware-determined space входит UDP в качестве Transport Layer, поверх которого как раз и работает QUIC.

Подобная архитектура протокола HTTP/3 как раз и обещает куда большую гибкость, стабильность и защищенность 🔒 А про обеспечивающие подобные преимущества UDP и QUIC - мы расскажем во второй части этого поста завтра ❤️

HTTP/3, QUIC и в чем революция, Джони? Часть 2

Из прошлого поста у некоторых мог возникнуть вопрос, что за UDP и куда делся старый добрый TCP? 🤔 Спешим ответить, что TCP еще никуда не делся и еще долго не денется, поскольку многие заслуженно считают его проверенным и надежным решением.

Но QUICK и лежащий в его основе UDP призваны заменить TCP, сделав передачу данных куда быстрее и стабильнее за счет обхода ограничений TCP 🔐

📌 TCP не поддерживает мультиплексирование на уровне потока. Иначе говоря, TCP потоки могут быть заблокированы, даже если сегменты с более высоким номером уже получены, но с менее высоким еще нет.

📌 TCP использует избыточный трафик. Даже если соединение произведено с уже известным хостом, TCP все еще использует стандартную последовательность сообщений.

Что же предлагает QUIC и UDP? 🔏

📌 Не требует внесения изменений в ядро. Как было сказано ранее, QUIC создается на уровне пользователя, а значит при внесении изменений при обновлении протокола, это не будет требовать внесения изменений в ядро.

📌 Мультиплексирование потоков. QUIC вводит мультиплексирование потоков и раздельное управление для каждого потока, что позволит устранить ранее озвученную проблему, также известную как Блокировка начала очереди.

📌 Устранение избыточных сообщений и увеличение скорости. QUIC оптимизирован так, чтобы избежать избыточного обмена протоколами с уже установленными хостами за счет оптимизации передачи и подтверждения приема (Round-Trip Times).

📌 Улучшение push. Push-уведомления сервера могут рассматриваться как ожидание запроса, из-за чего они занимают полосу пропускания. HTTP/3 предлагает push_promise, который отправляется с сервера и показывает ожидаемое содержание push, на который сам push будет ответом в новом потоке.

📌 Гибкое управление перегрузками. Конечно, все эти и многие другие механизмы QUIC позволяют куда более эффективно использовать полосу пропускания и намного более гибко управлять перегрузками.

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

Не пропустите заключительную часть этого поста завтра. В ней мы расскажем о значении всего этого для различных индустрий и поделимся ценными ресурсами ❤️

HTTP/3, QUIC и в чем революция, Джони? Часть 3

Что же, отойдем немного от технической стороны, поскольку здесь стоило бы сказать еще очень многое, а для некоторых такая информация будет избыточной и они просто хотят узнать зачем это все? ☝️

HTTP/3 позволяет сделать сеть намного более быстрой, гибкой, стабильной и защищенной, что критически важно во всех индустриях, активность в которых растет с каждым днем.

🚦 IoT или Интернет Вещей нуждается в постоянном подключении и бесперебойному обмену данными для выполнения своего самого прямого назначения, работе множества различных устройств как единой системы.

📊 FinTech и Финансовые Рынки нуждаются в наиболее быстрой работе сетей, поскольку каждая секунда там может стоить миллионы, а также в максимальной надежности сетей, чтобы возможность перехвата данных и увода средств была сведена к нулю.

🎮 AR/VR и Метавселенные нуждаются в огромном количестве данных, передающихся на наивысшей скорости, чтобы просто работать на том уровне, ради которого они создавались. И этот список можно продолжать еще долго.

Как вы могли понять, это невероятно объемная тема, а значение ее для будущего интернета несет самое принципиальное значение, поэтому если хотите подробную статью с разбором технологий, сервисов и прочего, дайте знать нам в комментариях 🤌

А пока может ознакомиться со списком библиотек, которые уже сейчас поддерживают HTTP/3?

📌 Quiche интерфейс для отправки и получения пакетов по протоколу QUIC, с поддержкой для приложений на iOS и Android, а также неофициальным плагином для NGINX.

📌 Aioquic реализация QUIC для Python на основе структуры асинхронного ввода-вывода.

📌 Neqo реализация QUIC от Mazilla с использованием Rust.

В 2022 году Зайад Хан создал термин Quit Quitting (Тихое увольнение). Суть его в том, люди отказываются от культуры достигаторства и суеты в пользу баланса между работой и личной жизнью.

Интересно то, что это не обязательно увольнение в прямом смысле. Речь идет скорее о том, чтобы работать только в рабочее время, отказаться от переработок и дополнительных задач, а также брать обязательный отпуск по графику с полной блокировкой рабочих контактов.

Приметами Тихого увольнения считаются:
📌 Циничность
📌 Низкая мотивация и вовлеченность
📌 Приоритеты вне работы

По сути, это энергосберегающий режим,🔋 который предотвращает выгорание, тревожность и депрессию из-за работы.

В чем может быть причина:
🔻 Напряженный график
🔻 Высокая нагрузка
🔻 Низкая зарплата
🔻 Токсичная среда в коллективе

Знакомы с этим термином? Был ли у вас опыт Тихого увольнения? 🤔

🔥 Прожарка 🔥

Сегодня в 18:00 (время по Бишкеку) два опытных эксперта соберутся вместе и в прямом эфире прожарят резюме кандидатов, претендующих на ИТ-позиции.

Маргарита Мысина - IT-recruiter & HR Specialist, Mad Devs и
Канышай Курманалиева - Head of HR Department, Finance Soft разберут несколько резюме, дадут свои комментарии и подскажут, как сделать их лучше!

Эфир пройдет в Telegram-канале Creative Asia.

HR Day уже завтра ⚡️

Наш первый профессиональный митап для HR-специалистов работающих в IT состоится уже завтра 25 февраля.
Напоминаем, регистрация участников начинается в 10:30, а сам ивент стартует в 11:00.

Коротко о спикерах и докладах:

📌 Маргарита Мысина, рекрутер в Mad Devs выступит с темой «Держите одеяло у себя: как общаться с кандидатом и узнавать все, что вам интересно».

📌Клара Абдукова, HR-специалист в Mad Devs расскажет о «Дружелюбном онбординге: как с увеличением количества не потерять качество»

📌Айгуль Абдрахманова, Talent Manager в Kanda CA выступит с докладом «Оценка сотрудников: важный компонент эффективного управления и удержания персонала»

Кроме того, вас ждут живые дискуссии и нетворкинг-салон. Этот ламповый ивент - отличная возможность расширить круг профессиональных знакомств, обзавестись новыми связями и обменяться опытом.

Ждем участников по адресу:
Ибраимова 115/1, 8 этаж, офис ИТ-Академии
Регистрация на месте с 10:30, стартуем в 11:00.

Участие в ивенте совершенно бесплатное и вы все еще можете зарегистрироваться на ивент здесь.

Hardhat Mad Boiler

В Mad Devs мы работаем с множеством рабочих окружений. Стремясь постоянно улучшать свою работу, мы собрали множество плагинов и зависимостей, которые используем в работе со смарт-контрактами воедино и создали собственное рабочее окружение, о котором расскажем вам сегодня. Встречайте, Hardhat Mad Boiler с набором встроенных утилит помогающих в разработке и тестировании HardHat Ethereum смарт контрактов 🤘

https://github.com/maddevsio/hardhat-mad-boiler

Каковы преимущества?

📌 Предварительно настроенный linter и средства форматирования для TypeScript и Solidity поможет сэкономить усилия по поддержанию чистой кодовой базы и сосредоточиться на разработке функций продукта.
📌 Система вывода типов TypeScript, поможет избежать ошибок в скриптах и тестах, и улучшить их качество.
📌 Поддержка файлов .env для управления учетными данными и легкого доступа к ним из скриптов и тестов.
📌 Рабочий процесс GitHub Actions, позволит применить практику непрерывной интеграции без дополнительных усилий.
📌 Дополнительные возможности разработки, доступные в виде расширений.

Какие возможности и расширения поддерживаются?

📌 Поддержка широко используемых примитивов и компонентов для разработки и обновления смарт-контрактов OpenZeppelin.
📌 Поддержка файлов .env в тестах и скриптах.
📌 Реализация кошелька и утилиты на JavaScript и TypeScript.
📌 Утилита для покрытия кода для тестирования Solidity.
📌 Упрощенный экспорт ABI смарт-контрактов при компиляции через Hardhat.
📌 Утилита для оценки размера байт кода для скомпилированных смарт-контрактов.
📌 Утилита для оценки использования газа для выполненных модульных тестов.
📌 Поддержка TypeScript.
📌 Автоматизированное форматирование кода для JavaScript, TypeScript и Solidity.
📌 Поддержка линтера ESLint для TypeScript.
📌 Поддержка линтера SolHint для Solidity.
📌 Поддержка сервиса проверки смарт-контрактов EtherScan для HardHat.

Звучит солидно, не правда ли? 👀
Проект продолжает свое активное развитие и мы будем рады вашему участию!
Надеемся на ваши скачивания, использование и комментарии! ❤️

Ну что немного отвлечемся и порешаем логические задачи? Завтра опубликуем свое решение, а вы в комментариях делитесь своими вариантами. Готовы? 😈

Итак,
Программисту на заводе по производству аккумуляторов было поручено разработать программное обеспечение, способное контролировать качество выпускаемой продукции. Два важных условия:
🔋 Каждая произведенная батарея имеет 2% шанс оказаться бракованной.
🔋 Система контроля качества выявляет нерабочие батареи в 98% случаев, но при этом в 1% случаев ошибочно определяет рабочие батареи как бракованные.

Разработчик должен определить среднее количество бракованных батарей в партии из 10 000 штук.

Как это решить?⬇️

Пришло время показать решение этой логической задачи. Скорее читаем и сравниваем со своим результатом 🤓

Начнем с выяснения вероятности брака у батареек. Предположим, вероятность выпуска брака составляет – 0,02. Тогда вероятность изготовления рабочей батарейки составляет 0,98.
Далее, рассчитаем:

Вероятность ошибки системы контроля, забраковывая рабочую батарейку:
0,01 * 0,98 = 0,0098
Вероятность обнаружения брака:
0,98 * 0,02 = 0,0196
Для нахождения вероятности отбраковки любой батарейки выполним сложение этих значений:
0,0098 + 0,0196 = 0,0294.

Помним, что в партии 10 000 батареек? Ну тогда дальше просто:
10 000 * 0,0294 = 294

Вуаля! ✨ Это и есть среднее количество бракованных батареек. Ну, кто решил задачу верно?

Хотите еще больше таких задачек? Оставьте нам реакцию. ❤️

Как вы думаете, сколько решений имеет эта задача? Как оказалось, не одно.

Очень круто, что обсуждение задачи из нашего телеграм канала перекочевало и продолжилось в оффлайне. Мы получили довольно много гипотез о том, какое же решение является правильным, а ответ наиболее точным, и сейчас хотим поделиться одним из них.

Для решения этой задачи можно использовать биномиальное распределение. Если X - количество бракованных батарей в партии из 10 000 штук, то тогда X имеет биномиальное распределение с параметрами n=10000 и p=0.02 (вероятность брака).

Согласно условиям задачи, система контроля качества выявляет нерабочие батареи в 98% случаев, но при этом в 1% случаев ошибочно определяет рабочие батареи как бракованные. Это значит, что если батария действительно бракованная, то с вероятностью 0.98 она будет определена как бракованная, а если батария действительно рабочая, то с вероятностью 0.01 она будет ошибочно определена как бракованная. Таким образом, вероятность того, что батария будет определена как бракованная, равна:

P(брак) = 0.02 * 0.98 + 0.98 * 0.01 = 0.0296

Теперь можно найти среднее количество бракованных батарей в партии из 10 000 штук, используя формулу для биномиального распределения:

E(X) = n * p = 10000 * 0.02 = 200

Ожидается, что в партии из 10 000 батарей будет 200 бракованных батарей.

Интересно, правда? Кто решал так же? Поделитесь в комментариях как быстро и почему вы выбрали такое решение ⬇️

Нейробиологический фундамент продуктивности 🧠

Наверное, каждый из нас задумывался о том, что неплохо бы в целях личной эффективности заиметь 25 час в сутках или таблетку из фильма “Области тьмы”. Стать более продуктивным вам могут помочь нейрогормоны о которых сегодня поговорим.

Конкретные нейрогормоны и их соотношение друг с другом могут стать ключом к вашей продуктивности. Первым элементом в этой связи выступает адреналин ⚡

📍 Выделение адреналина – общий фон продуктивности и эффективности.
📍 Синтез адреналина интевсивнее всего в голубом пятне, “щупальцы” которого проходят через структуру мозга.
📍 Эффект адреналина – работа по сценарию: бить, бежать, замереть (вот он нам и нужен в работе).

Замирание важно для выполнения задач, а именно в этот момент тело остается недвижимым, а мозговая активность на пределе. Как результат, задачки щелкаются, как семечки. Вы в потоке, вы в ресурсе 💪

🤝 Немаловажный тандем гормонов – «адреналин + ацетилхолин», где адреналин отвечает за бодрость и включенность, а ацетилхолин – за воплощение мыслей в действия.

Ацетилхолин помогает нам ориентироваться в работе, маневрировать среди целей. Есть пару “но”:

📍 Много ацетилхолина = уйдете в работу с головой и будете бегать, как крыса в колесе.
📍 Мало ацетилхолина = будете метаться между частями задачи и не знать, с какой стороны подойти, что приведёт к прокрастинации.

🤝 Следующая пара, которая помогает нам в работе, – «дофамин и норадреналин». Они похожи друг на друга, но выполняют разные задачи. Дофамин в комплексе с адреналином и ацетилхолином – топливо для концентрации и фокусировки. Чем дольше он выделяется, тем дольше состояние продуктивности.

Как увеличить рост этих нейрогормонов?

📍 Естественным образом. Это могут быть интенсивная работа или прохождение сложной миссии в игре.
📍 Механическим образом. Это могут быть концентрация на задачах, которые зависят от вас. Или же однозначный старт, когда поэтапно выполняете все действия. Поможет и дедлайн, который обеспечит высвобождение адреналина, и вы будете работать на пределе. Быстрые задачки, которые решаются за час-полтора.
📍 Фармакологический способ. У данных инструментов есть свои особенности, которые могут привести к неприятным последствиям при неправильном применении. Необходима консультация специалиста.

Для повышения интеллекта очень важно понимать, что вы делаете. Бессмысленно это делать при помощи ноотропов, режима дня и фармы, если у вас нет желания и попыток двигаться к новым знаниям, умениям и навыкам.

Ошибки при изучении Python или 5 стадий принятия неизбежного

“Ученье – свет, а неученье – тьма”. Все мы слышали эту пословицу. Но никто не предупреждал, что путь ученья бывает тернист и что очень легко допустить ошибку. И чтобы вы не допускали ошибок в будущем, мы разобрали 5 ошибок при изучении Python.

✍️ Первая и самая простая ошибка – начинать изучение Python с чужого кода, а не с терминологии и концепции языка программирования.

Разберитесь с понятийным аппаратом, составьте собственный словарь. Изучите элементы Python. После чего вы можете приступать к написанию собственного кода. Изучать чужой код полезно, если у вас уже есть опыт. Это помогает найти новые решения и оптимизировать свой код. Тем самым вы повышаете собственную насмотренность.

✍️ Вторая - отказ от поиска и сравнения разных инструментов для оптимального решения задач.

Прежде чем начать работать с кодом, изучите альтернативные варианты, которые могут оказаться проще в обращении,. А еще вы получите новые знания. Тем самым вы можете выбрать инструмент, исходя из своих предпочтений.

✍️ Третья ошибка - создавать промежуточные ручные решения, снижающие универсальность кода и уровень его автоматизации.

Если вы используете сразу две программы, то разузнайте о решениях внутри Python. Существует большая библиотека, в которой уже, возможно, существуют нужные вам методы.

✍️ Четвертая - делать скрипт нечитаемым, пренебрегая структурой.

Старайтесь во время написания кода внимательно относиться к новым переменным, подписывайте зачем они нужны, убирайте лишний блоки. Важно структурировать свой код. Позже для оформления кода можно использовать PEP 8 – руководство по стилю кода Python. Можете использовать для анализа инструменты, например, pycodestyle, prospector и пр. Не забудьте о пользовательских функциях.

✍️ Пятая ошибка - не сохранять удачные решения в базу знаний.

Создание собственной базы данных удачных решений поможет вам сэкономить ваше время. Например, если у вас есть задачи, с которыми вы часто сталкиваетесь, то сохраните код с описанием и примерами, чтобы было проще найти.

Не бойтесь допускать ошибки, но и не забывайте их исправлять. Расскажите в комментариях о своих ошибках в обучении, которые помогли вам👇

АНТИсоветы начинающим разработчикам

❗️Сначала изучить ВСЮ спецификацию языка, а потом учиться писать код
Если хотите качественный продукт, то делайте все сами от UX/UI дизайна до тестов. Все сами!
❗️ Код 24/7 – никогда не останавливайтесь и не отдыхайте. Забудьте о друзьях, семье. Только так придет успех, деньги, слава.
❗️ Никогда не пишите комментарии к коду. Там же итак все понятно и очевидно.
❗️Один стек наработали и хватит. Не изучайте ничего нового.
❗️Разработчики никогда не ошибаются. Все должно работать с первого раза, иначе меняйте профессию. Не созданы вы для этого.
❗️Тру разработчик не использует готовых решений и инструментов. Все пишет вручную. Все эти библиотеки, шаблоны, фреймворки – плагиат.
❗️Git для слабаков. Весь процесс разработки должен быть в голове. Мерджи, пуши, коммиты – зачем тратить лишние ресурсы.
❗️Дайте себе свободу. Захотели написать весь код в одну строчку – почему нет? Все эти методологии, ограничения, соглашения только мешают вам.

Но это все, конечно, шутки. 😆 Но не стесняйтесь добавить и свои вредные советы из личного опыта в комментариях. Явно у вас были свои забавные случаи, которые создали ваш личный "кодекс правил" в программировании. ⬇️